Re: Line numbers in backtraces (2017)
On Tuesday, 31 October 2017 at 11:21:30 UTC, Moritz Maxeiner wrote: On Tuesday, 31 October 2017 at 11:04:57 UTC, Tobias Pankrath wrote: [...] ??:? pure @safe void std.exception.bailOut!(Exception).bailOut(immutable(char)[], ulong, const(char[])) [0xab5c9566] ??:? pure @safe bool std.exception.enforce!(Exception, bool).enforce(bool, lazy const(char)[], immutable(char)[], ulong) [0xab5c94e2] I've found this StackOverflow Question from 2011 [1] and if I remember correctly this could be fixed by adding -L--export-dynamic which already is part of my dmd.conf [...] [1] https://stackoverflow.com/questions/8209494/how-to-show-line-numbers-in-d-backtraces Does using dmd's `-g` option (compile with debug symbols) not work[1]? [1] This is also what the answer in your linked SO post suggest? Of course I've tried this.
Re: "version" private word
On Tuesday, October 31, 2017 20:36:57 Jacob Carlborg via Digitalmars-d-learn wrote: > On 2017-10-31 16:36, Dr. Assembly wrote: > > thanks. I just find it werid, maybe because I came from C/C++ > > background, where it means only integer types. So enum s = "foo"; is > > really werid. But I'll get used to it. > > Think of it more like #define in C/C++ than "const". The above defines a > manifest constant that are only available at compile time, i.e. you > cannot take the address of a manifest constant. Yeah, thinking about them as const would be bad. All enums (whether they're manifest constants or actual enum types) effectively get copy-pasted when they're used, and in the case of arrays, that can be really important to understand. String literals aren't a problem, but an enum that is any other type of dynamic array is going to end up allocating a new array every time you use it, whereas if you had a variable at module-scope or a static variable (regardless of whether the variable was mutable, const, or immutable), then there's an actual memory location involved, and the copy-pasting doesn't happen. But enums in general in D (both manifest constants and actual enum types) can be more than just int (though string is probably the most common aside from int). They can be pretty much any type whose values can be known at compile time, even including things like structs. So, while enum types _are_ int by default just like in C, D's enums are actually _way_ more powerful than C's enums. - Jonathan M Davis
Re: "version" private word
On Tuesday, 31 October 2017 at 13:55:56 UTC, Igor Shirkalin wrote:
On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg
wrote:
On 2017-10-31 14:46, Igor Shirkalin wrote:
Hello!
We need some conditional compilation using 'version'.
Say we have some code to be compiled for X86 and X86_64.
How can we do that using predefined (or other) versions?
Examples:
version(X86 || X86_64) // failed
version(X86) || version(X86_64) // failed
The following works but it is too verbose:
version(X86) {
version = X86_or_64;
}
version(X86_64) {
version = X86_or_64;
}
The only alternative is to do something like this:
version (X86)
enum x86 = true;
else
enum x86 = false;
else version (X86_64)
enum x86_64 = true;
else
enum x86_64 = false;
static if (x86 || x86_64) {}
Got it. Thank you!
Yeah, in Diamond I went with this approach to make conditional
compilation around the project much easier.
https://github.com/DiamondMVC/Diamond/blob/master/core/apptype.d
Re: "version" private word
On 2017-10-31 16:36, Dr. Assembly wrote: thanks. I just find it werid, maybe because I came from C/C++ background, where it means only integer types. So enum s = "foo"; is really werid. But I'll get used to it. Think of it more like #define in C/C++ than "const". The above defines a manifest constant that are only available at compile time, i.e. you cannot take the address of a manifest constant. -- /Jacob Carlborg
Re: "version" private word
On Tuesday, 31 October 2017 at 15:19:49 UTC, Steven Schveighoffer wrote: On 10/31/17 10:47 AM, Igor Shirkalin wrote: [...] Sorry I hate writing code on mobile. You can create an arbitrary version by assigning a symbol to it, use that symbol to describe a feature, assign that symbol for each architecture that supports it. Then write code in a version block of that symbol. The question was not about mobile platforms. I think he meant he didn't like writing code in a forum post on his mobile, so he wrote something more abstract :) Ah. :) Sometimes we need to mix some combinations of code in one big project with or without some libraries, algorithms etc. I see what you mean and practically agree with you. But not everything depends on you (us). The above response has been the standard D answer for as long as this question has been asked (and it has been asked a lot). Walter is dead-set against allowing boolean expressions in version statements. Now I understand the irritation about my question. I'm sorry. The anointed way is to divide your code by feature support, and then version those features in/out based on the platform you are on. For example, instead of "X86_or_X64", you would do "TryUsingSSE" or something (not sure what your specific use case is). This doesn't solve the case with combinations of different versions. Four different versions produce nine (+4) different variants. It's stupid to define 9 additional version constants. However, enums and static if can be far more powerful. Version statements do not extend across modules, so you may have to repeat the entire scaffolding to establish versions in multiple modules. Enums are accessible across modules. Yes, it's now clear for me what to do. Thanks!
Re: "version" private word
On Tuesday, 31 October 2017 at 15:20:31 UTC, Igor Shirkalin wrote:
On Tuesday, 31 October 2017 at 14:54:27 UTC, Dr. Assembly wrote:
On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg
wrote:
On 2017-10-31 14:46, Igor Shirkalin wrote:
[...]
The only alternative is to do something like this:
version (X86)
enum x86 = true;
else
enum x86 = false;
else version (X86_64)
enum x86_64 = true;
else
enum x86_64 = false;
static if (x86 || x86_64) {}
Why is that keyword called enum? is this any related to the
fact enumeration's field are const values? it would be called
invariable or something?
You're right. Enum defines constant or group of constants in
compile time.
The full description of enum can be found here:
https://dlang.org/spec/enum.html
thanks. I just find it werid, maybe because I came from C/C++
background, where it means only integer types. So enum s = "foo";
is really werid. But I'll get used to it.
Re: "version" private word
On Tuesday, 31 October 2017 at 14:54:27 UTC, Dr. Assembly wrote:
On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg
wrote:
On 2017-10-31 14:46, Igor Shirkalin wrote:
[...]
The only alternative is to do something like this:
version (X86)
enum x86 = true;
else
enum x86 = false;
else version (X86_64)
enum x86_64 = true;
else
enum x86_64 = false;
static if (x86 || x86_64) {}
Why is that keyword called enum? is this any related to the
fact enumeration's field are const values? it would be called
invariable or something?
You're right. Enum defines constant or group of constants in
compile time.
The full description of enum can be found here:
https://dlang.org/spec/enum.html
Re: "version" private word
On 10/31/17 10:47 AM, Igor Shirkalin wrote: On Tuesday, 31 October 2017 at 14:31:17 UTC, Jesse Phillips wrote: On Tuesday, 31 October 2017 at 14:25:19 UTC, Igor Shirkalin wrote: On Tuesday, 31 October 2017 at 14:22:37 UTC, Jesse Phillips wrote: On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin wrote: Hello! You goal should be to describe features. Version x86 ... Version = I can stand on my head ... pardon? Sorry I hate writing code on mobile. You can create an arbitrary version by assigning a symbol to it, use that symbol to describe a feature, assign that symbol for each architecture that supports it. Then write code in a version block of that symbol. The question was not about mobile platforms. I think he meant he didn't like writing code in a forum post on his mobile, so he wrote something more abstract :) Sometimes we need to mix some combinations of code in one big project with or without some libraries, algorithms etc. I see what you mean and practically agree with you. But not everything depends on you (us). The above response has been the standard D answer for as long as this question has been asked (and it has been asked a lot). Walter is dead-set against allowing boolean expressions in version statements. The anointed way is to divide your code by feature support, and then version those features in/out based on the platform you are on. For example, instead of "X86_or_X64", you would do "TryUsingSSE" or something (not sure what your specific use case is). However, enums and static if can be far more powerful. Version statements do not extend across modules, so you may have to repeat the entire scaffolding to establish versions in multiple modules. Enums are accessible across modules. -Steve
Re: "version" private word
On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg wrote:
On 2017-10-31 14:46, Igor Shirkalin wrote:
Hello!
We need some conditional compilation using 'version'.
Say we have some code to be compiled for X86 and X86_64.
How can we do that using predefined (or other) versions?
Examples:
version(X86 || X86_64) // failed
version(X86) || version(X86_64) // failed
The following works but it is too verbose:
version(X86) {
version = X86_or_64;
}
version(X86_64) {
version = X86_or_64;
}
The only alternative is to do something like this:
version (X86)
enum x86 = true;
else
enum x86 = false;
else version (X86_64)
enum x86_64 = true;
else
enum x86_64 = false;
static if (x86 || x86_64) {}
Why is that keyword called enum? is this any related to the fact
enumeration's field are const values? it would be called
invariable or something?
Re: "version" private word
On Tuesday, 31 October 2017 at 14:31:17 UTC, Jesse Phillips wrote: On Tuesday, 31 October 2017 at 14:25:19 UTC, Igor Shirkalin wrote: On Tuesday, 31 October 2017 at 14:22:37 UTC, Jesse Phillips wrote: On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin wrote: Hello! You goal should be to describe features. Version x86 ... Version = I can stand on my head ... pardon? Sorry I hate writing code on mobile. You can create an arbitrary version by assigning a symbol to it, use that symbol to describe a feature, assign that symbol for each architecture that supports it. Then write code in a version block of that symbol. The question was not about mobile platforms. Sometimes we need to mix some combinations of code in one big project with or without some libraries, algorithms etc. I see what you mean and practically agree with you. But not everything depends on you (us).
Re: "version" private word
On Tuesday, 31 October 2017 at 14:25:19 UTC, Igor Shirkalin wrote: On Tuesday, 31 October 2017 at 14:22:37 UTC, Jesse Phillips wrote: On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin wrote: Hello! You goal should be to describe features. Version x86 ... Version = I can stand on my head ... pardon? Sorry I hate writing code on mobile. You can create an arbitrary version by assigning a symbol to it, use that symbol to describe a feature, assign that symbol for each architecture that supports it. Then write code in a version block of that symbol.
Re: "version" private word
On Tuesday, 31 October 2017 at 14:22:37 UTC, Jesse Phillips wrote: On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin wrote: Hello! You goal should be to describe features. Version x86 ... Version = I can stand on my head ... pardon?
Re: "version" private word
On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin wrote: Hello! You goal should be to describe features. Version x86 ... Version = I can stand on my head ...
Re: "version" private word
On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg wrote:
On 2017-10-31 14:46, Igor Shirkalin wrote:
Hello!
We need some conditional compilation using 'version'.
Say we have some code to be compiled for X86 and X86_64.
How can we do that using predefined (or other) versions?
Examples:
version(X86 || X86_64) // failed
version(X86) || version(X86_64) // failed
The following works but it is too verbose:
version(X86) {
version = X86_or_64;
}
version(X86_64) {
version = X86_or_64;
}
The only alternative is to do something like this:
version (X86)
enum x86 = true;
else
enum x86 = false;
else version (X86_64)
enum x86_64 = true;
else
enum x86_64 = false;
static if (x86 || x86_64) {}
Got it. Thank you!
Re: "version" private word
On 2017-10-31 14:46, Igor Shirkalin wrote:
Hello!
We need some conditional compilation using 'version'.
Say we have some code to be compiled for X86 and X86_64.
How can we do that using predefined (or other) versions?
Examples:
version(X86 || X86_64) // failed
version(X86) || version(X86_64) // failed
The following works but it is too verbose:
version(X86) {
version = X86_or_64;
}
version(X86_64) {
version = X86_or_64;
}
The only alternative is to do something like this:
version (X86)
enum x86 = true;
else
enum x86 = false;
else version (X86_64)
enum x86_64 = true;
else
enum x86_64 = false;
static if (x86 || x86_64) {}
--
/Jacob Carlborg
"version" private word
Hello!
We need some conditional compilation using 'version'.
Say we have some code to be compiled for X86 and X86_64.
How can we do that using predefined (or other) versions?
Examples:
version(X86 || X86_64) // failed
version(X86) || version(X86_64) // failed
The following works but it is too verbose:
version(X86) {
version = X86_or_64;
}
version(X86_64) {
version = X86_or_64;
}
- IS
Re: Line numbers in backtraces (2017)
On Tuesday, 31 October 2017 at 11:04:57 UTC, Tobias Pankrath wrote: [...] ??:? pure @safe void std.exception.bailOut!(Exception).bailOut(immutable(char)[], ulong, const(char[])) [0xab5c9566] ??:? pure @safe bool std.exception.enforce!(Exception, bool).enforce(bool, lazy const(char)[], immutable(char)[], ulong) [0xab5c94e2] I've found this StackOverflow Question from 2011 [1] and if I remember correctly this could be fixed by adding -L--export-dynamic which already is part of my dmd.conf [...] [1] https://stackoverflow.com/questions/8209494/how-to-show-line-numbers-in-d-backtraces Does using dmd's `-g` option (compile with debug symbols) not work[1]? [1] This is also what the answer in your linked SO post suggest?
Line numbers in backtraces (2017)
Hi, I'm using ArchLinux and the recent DMD from the Arch repositories and my backtraces show no line numbers. I now that is an old issue, but I'm back to D after a long pause and I thought that this used to work out of the box. My backtraces look likes this: ??:? pure @safe void std.exception.bailOut!(Exception).bailOut(immutable(char)[], ulong, const(char[])) [0xab5c9566] ??:? pure @safe bool std.exception.enforce!(Exception, bool).enforce(bool, lazy const(char)[], immutable(char)[], ulong) [0xab5c94e2] I've found this StackOverflow Question from 2011 [1] and if I remember correctly this could be fixed by adding -L--export-dynamic which already is part of my dmd.conf cat /etc/dmd.conf [Environment32] DFLAGS=-I/usr/include/dlang/dmd -L-L/usr/lib32 -L--export-dynamic -fPIC [Environment64] DFLAGS=-I/usr/include/dlang/dmd -L-L/usr/lib -L--export-dynamic -fPIC which is in fact read by dmd: % dmd -v DMD64 D Compiler v2.076.1 Copyright (c) 1999-2017 by Digital Mars written by Walter Bright Documentation: http://dlang.org/ Config file: /etc/dmd.conf How do I get useful back traces back? Thanks, Tobias [1] https://stackoverflow.com/questions/8209494/how-to-show-line-numbers-in-d-backtraces
Re: using .init reliably
On Tuesday, 31 October 2017 at 02:24:48 UTC, Steven Schveighoffer
wrote:
Yeah... my problem is, that I don't know it at compile time.
You know it at language time :)
:)
The .init property is provided by the compiler, unless you
define it. It means the default value of the type.
Here, I'm totally with you.
It belongs to the language. The init property should be only
allowed by the language. It doesn't need to be a keyword, but
it should not be allowed as a member function or field.
Take for example, the sizeof property. It can't be redefined.
Should be the init property of the same kind?
Should it be not redefinable at all, or only to guarantee, to get
a valid value? And if the latter, does it matter whether it as
evaluable at compile time?
If the former - I have no problem with this, it is just a
possibility to init an object in special cases.
In D, when you have overloads at different levels of priority,
it doesn't matter. Whatever has the highest priority owns all
the overloads.
For instance:
struct S
{
void foo(int x) {...}
}
void foo(S s, string x) {...}
void main()
{
S s;
s.foo("hi"); // error
}
Ok, I was not aware of this... And this quiet my mind a lot :)
My contention is that the language definition of init should
have the highest priority.
FYI: https://issues.dlang.org/show_bug.cgi?id=17954
Ok, cool. Thanks for that, and think, the first comment by Jakob
goes in the same direction, as I'm thinking of.
So, my current problem is solved by your code sample and the
different levels of priority hint.
Thanks a a lot :)
Re: Removing some of the elements from vibe.core.concurrency.Future[] futurelist
I'd take a look at why the error message says
`Future!(UserData)[]) to Future!(AnalyzeData)[]`
is AnalyzeData the type returned by ProcessResponceData?
Alternatively you could use a singly linked list and splice out
elements that pass the filter predicate. I think you'd have to
roll your own though.
I am sorry Wilson I normally in my code UserData is AnalyzeData =
UserData but I replace the name to make it more understandable.
For now I solved my problem like
vibe.core.concurrency.Future!(UserData)[] futurelist;
foreach( elem; elemList )
{
auto future = vibe.core.concurrency.async(
&elem.makeWebRequest );
futurelist ~= future;
}
int maximumSleepTime = 0;
while(futurelist.any!(a => !a.ready())) //--> Blocking until all
of them ready
{
maximumSleepTime++;
sleep(10.msecs);
if ( maximumSleepTime > 2000 )
return;
}
futurelist.each!(a=> Process(a.getResult()));
Unfortunately that is really bad when I make 250 web requests and
only one of them is bad(I mean not ready). And 249 request have
to wait for the bad one.
I will take a deeper look to data structure you suggested.
Thanks
