Re: Live without debugger?
On Monday, 10 November 2014 at 10:50:49 UTC, Chris wrote: On Sunday, 9 November 2014 at 08:26:59 UTC, Suliman wrote: I know that a lot of people are using for programming tools like Sublime. I am one of them. But if for very simple code it's ok, how to write hard code? Do you often need debugger when you are writing code? For which tasks debugger are more needed for you? I don't use a debugger for D. Most of the code I deal with is my own code anyway so I usually have a good idea of where things go wrong when they go wrong. But I think that it is also down to D being debug-friendly by nature (and I usually insert simple debug statements and / or unittests). In my experience, it doesn't even need an IDE. I think that's a sign of quality. What this guy said. I currently have a 20,000+ lines project and I haven't used a debugger once and have only done manual compiling; yet I haven't encountered any bugs or errors I haven't been able to fix within a short time; without going through a lot of code. I think I would probably have spend longer fixing bugs and errors using a debugger, breakpointing than simply analyzing code myself. All code is written by myself though and everything is documented, so I have a pretty good view over the project itself and anybody who decided to use it should have no problem navigating it either. Hands down to D for being as it is.
Re: practicality of empirical cache optimization in D vs C++
On Monday, 10 November 2014 at 19:18:21 UTC, Kirill wrote: Dear D community (and specifically experts on cache optimization), I'm a C++ programmer and was waiting for a while to do a project in D. I'd like to build a cache-optimized decision tree forest library, and I'm debating between D and C++. I'd like to make it similar to atlas, spiral, or other libraries that partially use static optimization with recompilation and meta-programming to cache optimize the code for a specific architecture (specifically the latest xeons / xeon phi). Given D's compile speed and meta-programming, it should be a good fit. The problem that I might encounter is that C++ has a lot more information on the topic, which might be significant bottleneck given I'm just learning cache optimization (from a few papers and what every programmer should know about memory). From my understanding, cache optimization mostly involves breaking data and loops into segments that fit in cache, and making sure that commonly used variables (for example sum in sum+=i) stay in cache. Assing there isn't more frequently accessed data around, you would want that to stay in a register, not cache. Most of this should be solved by statically defining sizes and paddings of blocks to be used for caching. It's more related to low level -- C, from my understanding. Are there any hidden stones? The other question is how mature is the compiler in terms of optimizing for cache comparing to C++? I think gnu C++ does a few tricks to optimize for cache and there are ways to tweak cache line alignment. My knowledge on the subject is not yet concrete and limited but I hope this gave an idea of what I'm looking for and you can recommend me a good direction to take. Best regards, --Kirill D is a good language for this sort of thing. Using various metaprogramming techniques it might even be fun. Most advice for C(++) will also apply to D w.r.t. cache. You will probably have to learn assembly and also make use of tools such as cachegrind and perf unless you like trying to optimise blind. A word of warning: modern CPU caches are complicated and are sometimes difficult to understand w.r.t. performance in specific cases.
Re: cannot sort an array of char
IK For example, isRandomAccessRange[0] states the problem: IK - IK Although char[] and wchar[] (as well as their qualified IK versions including string and wstring) are arrays, IK isRandomAccessRange yields false for them because they use IK variable-length encodings (UTF-8 and UTF-16 respectively). IK These types are bidirectional ranges only. IK - IK but does not offer a solution. If (when) byCodeUnit does IK really provide a random-access range, it would be desirable to IK have it linked where the problem is stated. IK IK [0] http://dlang.org/phobos/std_range.html#.isRandomAccessRange MS I agree. But how should it be implemented? We would have to MS modify algorithms that require an RA range to also accept MS char[], but then print an error message with the suggestion to MS use byCodeUnit. I think that's not practicable. Any better MS ideas? I meant just mentioning a workaround (byCodeUnit or representation) in the documentation, not in a compiler error. But the latter option does have some sense, too.
Re: cannot sort an array of char
IK Why is char [] so special that it can't be sorted? SS Because sort works on ranges, and std.range has the view that SS char[] is a range of dchar without random access. Nevermind SS what the compiler thinks :) SS SS I believe you can get what you want with SS std.string.representation: SS SS import std.string; SS SS sort(c.representation); Thank you for showing a library way to do that. I ended up with using a cast, like sort (cast (ubyte []) c). And this looks like a safe way to do the same. Now, std.utf's byCodeUnit and std.string's representation seem like duplicate functionality, albeit with different input and output types (and bugs :) ).
Re: Russian translation of the range term?
On Tue, 11 Nov 2014 11:50:16 + Ivan Kazmenko via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Is there an official translation already? In TDPL, the (very few) occurrences of range are translated as диапазон methinks that последовательность[0] is better, albeit longer. but nobody will use that except 3.5 freaks, it's way too long. but диапазон is completely wrong anyway. [0] sequence, but without connotation of any ordering. signature.asc Description: PGP signature
Re: cannot sort an array of char
On 11/11/14 6:07 AM, Ivan Kazmenko wrote: IK Why is char [] so special that it can't be sorted? SS Because sort works on ranges, and std.range has the view that SS char[] is a range of dchar without random access. Nevermind SS what the compiler thinks :) SS SS I believe you can get what you want with SS std.string.representation: SS SS import std.string; SS SS sort(c.representation); Thank you for showing a library way to do that. I ended up with using a cast, like sort (cast (ubyte []) c). And this looks like a safe way to do the same. It's safe but be careful. For instance, if c becomes an immutable(char)[] or const(char)[], then you will have undefined behavior. If you use the representation, it will properly reject this behavior. Now, std.utf's byCodeUnit and std.string's representation seem like duplicate functionality, albeit with different input and output types (and bugs :) ). No, byCodeUnit is not an array, it's a range of char. They solve different problems, and mean different things. Note, byCodeUnit should work for sort, I'm surprised it doesn't. -Steve
How to use map?
I'm trying to do something simple like creating an array of
struct S from a float array via map:
---
void main()
{
float[] vals = [1.1, 2.1, 3.1, 4.1];
import std.algorithm: map;
auto arr = vals.map!`S(a)`.array;
writeln(arr);
}
struct S(T)
{
T t;
}
---
But I get:
---
C:\D\dmd2\windows\bin\..\..\src\phobos\std\functional.d-mixin-49(49):
Error: undefined identifier S
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(480):
Error: template instance std.functional.unaryFun!(S(a),
a).unaryFun!float error instantiating
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(427):
instantiated from here: MapResult!(unaryFun, float[])
src\app.d(28):instantiated from here: map!(float[])
---
If I instead do ie. map!`cast(int)a` it works fine.
What am I missing?
Re: How to use map?
Lemonfiend:
If I instead do ie. map!`cast(int)a` it works fine.
What am I missing?
Generally don't use casts, unless you know what you are doing
(and often you don't).
The code you were trying to write:
struct Foo(T) {
T t;
}
void main() {
import std.stdio, std.algorithm, std.array;
float[] vals = [1.1, 2.1, 3.1, 4.1];
auto arr = vals.map!(Foo!float).array;
arr.writeln;
}
Bye,
bearophile
Re: Russian translation of the range term?
Another synonym is list.
Re: How to use map?
The code you were trying to write:
struct Foo(T) {
T t;
}
void main() {
import std.stdio, std.algorithm, std.array;
float[] vals = [1.1, 2.1, 3.1, 4.1];
auto arr = vals.map!(Foo!float).array;
arr.writeln;
}
Sorry, my example had an unneeded template. Simply this (and also
your code)
---
struct S
{
float f;
}
---
still results in an undefined identifier.
Re: How to use map?
Oh, no it doesn't. My bad. It was all about !(Foo) vs !(`Foo(a)`). Is there somewhere I can read more about this?
Re: Russian translation of the range term?
On Tue, 11 Nov 2014 14:08:36 + Kagamin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Another synonym is list. hm... i afraid that it's not suitable. list has a well-defined meaning in programming literature. ranges are definitely not lists (but list can be a range). ah! набор! it's short, it not collides with well-defined terms, it describes what range is. it even consists of five letters! ;-) signature.asc Description: PGP signature
Re: Network scanner
OS WinXP
Re: status of D optimizers benefiting from contracts ?
On Monday, 10 November 2014 at 10:27:19 UTC, bearophile wrote: In practice I prefer to avoid using hacks like setting a NDEBUG. It's better to have differently named operators if their behavour is different. So it's better to keep the assert() as it is commonly used (and I'd like it to refuse a not pure expression). And add another operator, like strong_assert() for the NDEBUG=strong behavour. (And if you can't live with it, you can also add a strict_assert()). Changing the behavour of asserts just changing a global constant is silly because what matters is the semantics the programmer gives to the assert he/she/shi is using. So giving them different names is much better. In my experience asserts don't show such distinction, and it's impractical to decide such things in advance. So I think, a compiler switch makes more sense.
Re: Russian translation of the range term?
I was thinking about list comprehension, which is what programming on ranges is. Isn't it?
Re: Russian translation of the range term?
On Tue, 11 Nov 2014 14:52:55 + Kagamin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I was thinking about list comprehension, which is what programming on ranges is. Isn't it? list is a good term, but it's already taken. so naming range as list will create unnecessary confusion. alas. yet набор is short and easy, and it's not widely used, as set is translated as множество. but it's for OP to decide, of course. signature.asc Description: PGP signature
Re: Access Violation Tracking
On Saturday, 8 November 2014 at 15:51:59 UTC, Gary Willoughby wrote: This is really cool, (and at the risk of sounding foolish) what is the benefit of doing this? It turns segfault into normal exception with a stack trace, so you see where it failed right away.
Re: Network scanner
netstat reports that the socket is in the TIME_WAIT or CLOSE_WAIT state.
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 15:03:40 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 11 Nov 2014 14:52:55 + Kagamin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I was thinking about list comprehension, which is what programming on ranges is. Isn't it? list is a good term, but it's already taken. so naming range as list will create unnecessary confusion. alas. yet набор is short and easy, and it's not widely used, as set is translated as множество. but it's for OP to decide, of course. What does набор mean literally? What is it?
Re: Access Violation Tracking
On 11/11/14 10:14 AM, Kagamin wrote: On Friday, 7 November 2014 at 03:45:23 UTC, Steven Schveighoffer wrote: In an environment that you don't control, the default behavior is likely to print Segmentation Fault and exit. No core dump, no nothing. If you let the exception propagate into OS, by default Windows creates memory dump. Windows is a different story. You actually get a reasonable result. On Unix flavors, you get a signal, and by default, an exit, with the following message: Segmentation fault prompt No history, no core dump (generally this is off by default), no information as to where it occurred, why it occurred. Nothing. -Steve
Re: How to use map?
On Tuesday, 11 November 2014 at 14:09:43 UTC, Lemonfiend wrote:
Oh, no it doesn't. My bad.
It was all about !(Foo) vs !(`Foo(a)`). Is there somewhere I
can read more about this?
Don't know whether it's documented, but it's a consequence of
using string mixins.
unaryFun (which is used internally by map) is implemented this
way:
auto unaryFun(ElementType)(auto ref ElementType __a)
{
mixin(alias ~ parmName ~ = __a ;);
return mixin(fun);
}
where `fun` is `Foo(a)`. Of course, `Foo` is not visible in
std.functional. When you pass in a symbol, the lookup work
because it takes place at the point of instantiation.
Re: cannot sort an array of char
On Tuesday, 11 November 2014 at 13:20:53 UTC, Steven Schveighoffer wrote: On 11/11/14 6:07 AM, Ivan Kazmenko wrote: IK Why is char [] so special that it can't be sorted? SS Because sort works on ranges, and std.range has the view that SS char[] is a range of dchar without random access. Nevermind SS what the compiler thinks :) SS SS I believe you can get what you want with SS std.string.representation: SS SS import std.string; SS SS sort(c.representation); Thank you for showing a library way to do that. I ended up with using a cast, like sort (cast (ubyte []) c). And this looks like a safe way to do the same. It's safe but be careful. For instance, if c becomes an immutable(char)[] or const(char)[], then you will have undefined behavior. If you use the representation, it will properly reject this behavior. Now, std.utf's byCodeUnit and std.string's representation seem like duplicate functionality, albeit with different input and output types (and bugs :) ). No, byCodeUnit is not an array, it's a range of char. They solve different problems, and mean different things. Note, byCodeUnit should work for sort, I'm surprised it doesn't. That's what he meant by bugs :-P But it's been fixed already, thanks to H.S. Teoh.
Re: Network scanner
On Tue, 11 Nov 2014 15:35:28 + RuZzz via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: netstat reports that the socket is in the TIME_WAIT or CLOSE_WAIT state. i'm not an expert in winsock, but did you tried to set SO_LINGER to off? signature.asc Description: PGP signature
Re: Russian translation of the range term?
I was thinking about list comprehension, which is what programming on ranges is. Isn't it? list is a good term, but it's already taken. so naming range as list will create unnecessary confusion. alas. yet набор is short and easy, and it's not widely used, as set is translated as множество. but it's for OP to decide, of course. What does набор mean literally? What is it? As I see it, набор can informally be translated as collection, most frequently unordered and allowing duplicates. I often see and use it as a human-readable translation of the term multiset in texts which are not too formal (the exact translation мультимножество is way too long and scientific). The suggested translations диапазон (diapason), список (list), последовательность (sequence), набор (collection) all have something in common with the range concept, but all of them seem to have a defined meaning in either maths or computer science. Maybe it's inevitable, just like range is itself an overloaded term in English. Ivan Kazmenko.
Re: Russian translation of the range term?
On Tue, 11 Nov 2014 15:38:26 + Chris via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: What does набор mean literally? What is it? something like (unordered) set of something similar but not same, which can (eventually) be counted and things can be extracted/added. like this. набор ручек для писания, for example, as set of pens from which one pen can be taken and used (or another pen added to be used later). pretty similar to what range in D is, methinks. signature.asc Description: PGP signature
Re: Russian translation of the range term?
On Tue, 11 Nov 2014 15:38:26 + Chris via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Tuesday, 11 November 2014 at 15:03:40 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 11 Nov 2014 14:52:55 + Kagamin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I was thinking about list comprehension, which is what programming on ranges is. Isn't it? list is a good term, but it's already taken. so naming range as list will create unnecessary confusion. alas. yet набор is short and easy, and it's not widely used, as set is translated as множество. but it's for OP to decide, of course. What does набор mean literally? What is it? ah, yes, collection is a good translation. yet the word коллекция is used literally in some of the programming books. signature.asc Description: PGP signature
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 16:10:33 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 11 Nov 2014 15:38:26 + Chris via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Tuesday, 11 November 2014 at 15:03:40 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 11 Nov 2014 14:52:55 + Kagamin via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I was thinking about list comprehension, which is what programming on ranges is. Isn't it? list is a good term, but it's already taken. so naming range as list will create unnecessary confusion. alas. yet набор is short and easy, and it's not widely used, as set is translated as множество. but it's for OP to decide, of course. What does набор mean literally? What is it? ah, yes, collection is a good translation. yet the word коллекция is used literally in some of the programming books. Does that entail the concept that ranges (in D) are homogeneous (i.e. every member/item is of the same type)?
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 14:52:56 UTC, Kagamin wrote: I was thinking about list comprehension, which is what programming on ranges is. Isn't it? No, not really. It only applies to specific subset of ranges and specific interpretation of list term. There is no straightforward equivalence here.
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 16:00:56 UTC, Ivan Kazmenko wrote: The suggested translations диапазон (diapason), список (list), последовательность (sequence), набор (collection) all have something in common with the range concept, but all of them seem to have a defined meaning in either maths or computer science. Maybe it's inevitable, just like range is itself an overloaded term in English. Yes, this is pretty much the case. One can't find translation for a range that won't have any additional connotations because range is itself heavily overloaded word in English. In my opinion: диапазон is ok to describe a finite forward range последовательность is solid generic term if you are not afraid of making mathematicians mad I don't like список or набор because they don't necessarily imply iteration which is the most crucial aspect of range concept. In practice I think it is OK to use any of those terms if you use it consistently within a book / article and explain its meaning somewhere in the very beginning.
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 16:09:06 UTC, ketmar via Digitalmars-d-learn wrote: набор ручек для писания, for example, as set of pens from which one pen can be taken and used (or another pen added to be used later). pretty similar to what range in D is, methinks. Only if http://en.wikipedia.org/wiki/Axiom_of_choice is believed to be correct :)
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 16:14:10 UTC, Chris wrote: Does that entail the concept that ranges (in D) are homogeneous (i.e. every member/item is of the same type)? Yes (if you mean static type) ElementType!Range is used extensively in Phobos
Re: Russian translation of the range term?
On Tue, 11 Nov 2014 16:10:12 + Dicebot via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: последовательность is solid generic term if you are not afraid of making mathematicians mad and it is totally unusable in practice. it's just too long and hard to pronounce to be used anywhere except a dry boring book. ;-) i'm not forcing any of terms, but i believe that the term must be short or people will not adopt it. signature.asc Description: PGP signature
Re: Network scanner
On Tuesday, 11 November 2014 at 16:04:21 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 11 Nov 2014 15:35:28 + RuZzz via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: netstat reports that the socket is in the TIME_WAIT or CLOSE_WAIT state. i'm not an expert in winsock, but did you tried to set SO_LINGER to off? Closed ports stay in state WAIT for quite a while. If SO_LINGER=off doesn't help try to tune some Windows TCP parameters: - reduce TcpTimedWaitDelay from 120 to 30 seconds - use ports above 5000 - bigger port hash table Remember to reboot after stetting these registry values: REGEDIT4 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] TcpTimedWaitDelay=dword:001e MaxUserPort=dword:fffe MaxHashTableSize=dword: NumTcbTablePartitions=dword:8
Re: Russian translation of the range term?
On Tue, Nov 11, 2014 at 04:14:12PM +, Dicebot via Digitalmars-d-learn wrote:
On Tuesday, 11 November 2014 at 16:09:06 UTC, ketmar via Digitalmars-d-learn
wrote:
набор ручек для писания, for example, as set of pens from which
one pen can be taken and used (or another pen added to be used
later). pretty similar to what range in D is, methinks.
Only if http://en.wikipedia.org/wiki/Axiom_of_choice is believed to be
correct :)
That's not a problem:
auto choose(SoS /* pun intended */)(SoS sets)
if (isSetOfSets!SoS)
in { assert(axiomOfChoice); } // --- this makes it all work
body
{
return sets.choiceFunction();
}
;-)
T
--
Prosperity breeds contempt, and poverty breeds consent. -- Suck.com
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 16:15:36 UTC, Dicebot wrote: On Tuesday, 11 November 2014 at 16:14:10 UTC, Chris wrote: Does that entail the concept that ranges (in D) are homogeneous (i.e. every member/item is of the same type)? Yes (if you mean static type) ElementType!Range is used extensively in Phobos Sorry, I meant does the term набор (=collection) entail the concept that all items are of the same type? A collection could also be a loose collection of elements of different types (int, string, float, MyClass), whereas in D a range's elements can (usually) only be of one type.
Re: Russian translation of the range term?
On Tue, 11 Nov 2014 16:50:23 + Chris via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Tuesday, 11 November 2014 at 16:15:36 UTC, Dicebot wrote: On Tuesday, 11 November 2014 at 16:14:10 UTC, Chris wrote: Does that entail the concept that ranges (in D) are homogeneous (i.e. every member/item is of the same type)? Yes (if you mean static type) ElementType!Range is used extensively in Phobos Sorry, I meant does the term набор (=collection) entail the concept that all items are of the same type? A collection could also be a loose collection of elements of different types (int, string, float, MyClass), whereas in D a range's elements can (usually) only be of one type. on of the meaning is a collection of similar items, yes. or at least items with the similar purpose/property. signature.asc Description: PGP signature
Re: Russian translation of the range term?
On 11/11/2014 08:10 AM, ketmar via Digitalmars-d-learn wrote: What does набор mean literally? What is it? ah, yes, collection is a good translation. yet the word коллекция is used literally in some of the programming books. The separate concepts collection and range better have separate words. Ali
Re: Russian translation of the range term?
On Tuesday, 11 November 2014 at 18:39:09 UTC, Ali Çehreli wrote: The separate concepts collection and range better have separate words. Ali This is especially important because collection tends to have certain connotation with container and confusion between ranges and containers is a common mistake among D newbies.
passing duck-typed objects and retaining full type information
* i apologize in advance, this is my first post -- the code
formatting probably wont turn out so great...
I have a bunch of duck typed interfaces for containers similar
to what you would find in std.range.
i.e.
template isContainer(C)
{
enum bool isContainer = is(typeof(
(inout int = 0)
{
C c = C.init;
...
}));
}
template canRemoveFromContainer(C)
{
enum bool canRemoveFromContainer = isContainer!C is(typeof(
(inout int = 0)
{
C c = C.init;
c.remove();
}));
}
Now what i want to do is pass some such container object to an
interface function:
interface MyInterface
{
void filterCollisions(S)(S collisionCandidates)
if(canRemoveFromContainer!S)
}
but of coarse templates and interfaces don't get along so well.
so...so far as I know i would need to do something like this:
interface MyInterface
{
final void filterCollisions(S)(S collisionCandidates)
if(canRemoveFromContainer!S)
{
filterCollisionsImpl(...);
}
void filterCollisionsImpl(...)
}
and pass something to filterCollisionsImpl that is a proper
class or interface type.
So here's the problem: many of the duck-typed interfaces
cannot be converted to proper interfaces without losing
something. So is there ANY way to pass in
a very basic class or interface Container type and call the
remove function on it? Here's what i've tried:
interface Container(C)
{
...
}
template ContainerObject(C) if (isContainer!(Unqual!C)) {
static if (is(C : Container!(ElementType!C))) {
alias ContainerObject = C;
} else static if (!is(Unqual!C == C)) {
alias ContainerObject = ContainerObject!(Unqual!C);
} else {
static if (__traits(compiles, { enum e = C.ValueType; })) {
alias ValueType = C.ValueType;
} else {
alias ValueType = ElementType!C;
}
class ContainerObject : Container!ValueType {
C _container;
this(C container) {
this._container = container;
}
static if(canRemoveFromContainer!C) {
size_t remove()
{
return _container.remove();
}
}
}
}
}
ContainerObject!C containerObject(C)(C container) if
(isContainer!C) {
static if (is(C : Container!(ElementType!C))) {
return container;
} else {
return new ContainerObject!C(container);
}
}
interface MyInterface
{
final void filterCollisions(S)(S collisionCandidates)
if(canRemoveFromContainer!S)
{
auto container = containerObject(collisionCandidates);
container.remove(); // works just fine -- have the complete
type info at instantiation site
filterCollisionsImpl();
}
void filterCollisionsImpl(Container!string collisionCandidates)
collisionCandidates.remove(); // error -- some type info is lost
here, only have a Container!string which doesn't have a remove
function.
}
Re: How to use map?
On Tuesday, 11 November 2014 at 15:53:37 UTC, Marc Schütz wrote:
Don't know whether it's documented, but it's a consequence of
using string mixins.
unaryFun (which is used internally by map) is implemented this
way:
auto unaryFun(ElementType)(auto ref ElementType __a)
{
mixin(alias ~ parmName ~ = __a ;);
return mixin(fun);
}
where `fun` is `Foo(a)`. Of course, `Foo` is not visible in
std.functional. When you pass in a symbol, the lookup work
because it takes place at the point of instantiation.
That makes sense, thanks.
alias overloaded function template
D is fine with alias this overloaded function:
---
void foo(int t) {}
void foo(int t, int i) {}
alias bar = foo;
---
But isn't as happy aliasing these function templates:
---
void foo(T)(T t) {}
void foo(T)(T t, int i) {}
alias bar = foo!int;
---
Is there some way/other syntax to make an alias like this work?
Or specify in the alias which function template to use (ie. alias
bar = foo!int(int)).
insertInPlace differences between compilers
I'm trying to write a struct template that uses `insertInPlace`.
However, it doesn't work with certain template type / compiler
combinations. Consider the following:
import std.range;
struct S { const int c; }
S[] a;
insertInPlace(a, 0, S());
With DMD64 D Compiler v2.066.1, I get the following error:
/usr/include/dmd/phobos/std/array.d(1013): Error: cannot modify
struct dest[i] S with immutable members
/usr/include/dmd/phobos/std/array.d(1079): Error: template
instance std.array.copyBackwards!(S) error instantiating
./d/my_source_file.d(12345):instantiated from here:
insertInPlace!(S, S)
But with gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1), the same
code compiles.
While I'm still trying to get to grips with mutability in D, I
wonder which compiler/library's got it right or whether this is a
difference in language versions. The error still occurs when I
change the type of `c` to a const class which is the case I'd
really like this to work for.
I can avoid `insertInPlace` on DMD with the following, much
slower alternative:
a = a[0..insertionPoint] ~ element ~ a[insertionPoint..$];
In the short term, could anybody suggest a `static if` expression
to determine whether I can copy the type to the satisfaction of
`copyBackwards`? I tried isMutable but that didn't seem to work.
Thanks, John
Destructor/Finalizer Guarantees
I have a situation where I have a VM (virtual machine) object, and several GCRoot (garbage collector root objects). The GCRoots are structs and will register themselves into a linked list belonging to the VM. I've made it so they unregister themselves in their destructor. This works perfectly well for GC roots which are on the stack. However, recently, I ran into a case where I need GCRoots which are not on the stack. This is where things broke down. The VM object got destroyed before the GCRoots, and when these tried to unregister themselves, they accessed memory which had already been reclaimed (the dead VM). What I want to know is: what guarantees can I expect from destructor behavior? I was thinking that when the VM gets destroyed, it could unregister all of its GCRoots at once. Then, when these are destroyed, they wouldn't try to touch the VM object. However, this only works if I can assume that the GC will first call the destructor on an object, then free the object, that this is done in a predictable order. Am I on the right track, or do I need to rethink this?
Re: Destructor/Finalizer Guarantees
On Tue, 11 Nov 2014 22:31:17 + Maxime Chevalier-Boisvert via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: What I want to know is: what guarantees can I expect from destructor behavior? destructors *may* be called eventually. or not. in any order. but never twice. think about object destructors as finalizers. no calling order guarantees, nor even guarantees that something will be called at all. so if your VM becomes garbage, and registered objects are anchored only by VM (i.e. there are no more references to that objects), destructors can be called in any order. signature.asc Description: PGP signature
Re: Destructor/Finalizer Guarantees
As for guarantees for class destructors - you have hard guarantees that if memory is reclaimed, destructor was called before. But no guarantees memory will actually be reclaimed.
Re: Destructor/Finalizer Guarantees
There is an issue with structs that are directly allocated on heap - destructors are never called for those. You will want to change those into classes for GC to do at least something about it. See also this bug report : https://issues.dlang.org/show_bug.cgi?id=2834
Re: insertInPlace differences between compilers
On Tuesday, 11 November 2014 at 20:53:51 UTC, John McFarlane
wrote:
I'm trying to write a struct template that uses
`insertInPlace`. However, it doesn't work with certain template
type / compiler combinations. Consider the following:
import std.range;
struct S { const int c; }
S[] a;
insertInPlace(a, 0, S());
With DMD64 D Compiler v2.066.1, I get the following error:
/usr/include/dmd/phobos/std/array.d(1013): Error: cannot modify
struct dest[i] S with immutable members
/usr/include/dmd/phobos/std/array.d(1079): Error: template
instance std.array.copyBackwards!(S) error instantiating
./d/my_source_file.d(12345):instantiated from here:
insertInPlace!(S, S)
I believe DMD is correct here and here is why:
While the function is called insert the operation is actually
an assignment. DMD initializes all arrays elements to the default
value so your array position 0 actually contains an S already.
This means the operation is equivalent to
auto b = S();
b = S();
Since S is a value type you're actually making a modification 'c'
as stored in 'b'. The compiler is unable to prove that there is
no other reference to that same memory location (though in this
case the variable is on the stack and the modification is local
so such knowledge may be possible).
In the short term, could anybody suggest a `static if`
expression to determine whether I can copy the type to the
satisfaction of `copyBackwards`? I tried isMutable but that
didn't seem to work.
Thanks, John
You probably want std.traits.isAssignable
pragma(msg, isAssignable!(S, S)); // False
Re: passing duck-typed objects and retaining full type information
On Tuesday, 11 November 2014 at 19:23:39 UTC, Adam Taylor wrote:
* i apologize in advance, this is my first post -- the code
formatting probably wont turn out so great...
I have a bunch of duck typed interfaces for containers
similar to what you would find in std.range.
i.e.
template isContainer(C)
{
enum bool isContainer = is(typeof(
(inout int = 0)
{
C c = C.init;
...
}));
}
template canRemoveFromContainer(C)
{
enum bool canRemoveFromContainer = isContainer!C
is(typeof(
(inout int = 0)
{
C c = C.init;
c.remove();
}));
}
Now what i want to do is pass some such container object to
an interface function:
interface MyInterface
{
void filterCollisions(S)(S collisionCandidates)
if(canRemoveFromContainer!S)
}
but of coarse templates and interfaces don't get along so well.
so...so far as I know i would need to do something like this:
interface MyInterface
{
final void filterCollisions(S)(S collisionCandidates)
if(canRemoveFromContainer!S)
{
filterCollisionsImpl(...);
}
void filterCollisionsImpl(...)
}
and pass something to filterCollisionsImpl that is a proper
class or interface type.
So here's the problem: many of the duck-typed interfaces
cannot be converted to proper interfaces without losing
something. So is there ANY way to pass in
a very basic class or interface Container type and call the
remove function on it? Here's what i've tried:
interface Container(C)
{
...
}
template ContainerObject(C) if (isContainer!(Unqual!C)) {
static if (is(C : Container!(ElementType!C))) {
alias ContainerObject = C;
} else static if (!is(Unqual!C == C)) {
alias ContainerObject = ContainerObject!(Unqual!C);
} else {
static if (__traits(compiles, { enum e = C.ValueType; })) {
alias ValueType = C.ValueType;
} else {
alias ValueType = ElementType!C;
}
class ContainerObject : Container!ValueType {
C _container;
this(C container) {
this._container = container;
}
static if(canRemoveFromContainer!C) {
size_t remove()
{
return _container.remove();
}
}
}
}
}
ContainerObject!C containerObject(C)(C container) if
(isContainer!C) {
static if (is(C : Container!(ElementType!C))) {
return container;
} else {
return new ContainerObject!C(container);
}
}
interface MyInterface
{
final void filterCollisions(S)(S collisionCandidates)
if(canRemoveFromContainer!S)
{
auto container = containerObject(collisionCandidates);
container.remove(); // works just fine -- have the complete
type info at instantiation site
filterCollisionsImpl();
}
void filterCollisionsImpl(Container!string collisionCandidates)
collisionCandidates.remove(); // error -- some type info is
lost here, only have a Container!string which doesn't have a
remove function.
}
Not entirly sure of what you asking for,but have you tried
inhertance?
interface Base(C){
/+...+/
}
interface Derived(C):Base!C{
/+...+/
}
Re: passing duck-typed objects and retaining full type information
Not entirly sure of what you asking for,but have you tried
inhertance?
interface Base(C){
/+...+/
}
interface Derived(C):Base!C{
/+...+/
}
No, i'm specifically looking for a solution that is NOT
inheritance based. I've been looking at solutions based on
opDispatch or template mixins -- but so far haven't come up with
anything.
Re: passing duck-typed objects and retaining full type information
No, i'm specifically looking for a solution that is NOT
inheritance based. I've been looking at solutions based on
opDispatch or template mixins -- but so far haven't come up
with anything.
For example in this thread:
http://forum.dlang.org/thread/mailman.410.1319536838.24802.digitalmar...@puremagic.com?page=2
Adam Ruppe has an interesting example:
DynamicObject delegate(DynamicObject[] args) dynamicFunctions;
DynamicObject opDispatch(string name, T...)(T t) {
if(name !in dynamicFunctions) throw new
MethodNotFoundException(name);
DynamicObject[] args;
foreach(arg; t)
args ~= new DynamicObject(arg);
return dynamicFunctions[name](args);
}
Re: passing duck-typed objects and retaining full type information
On Wednesday, 12 November 2014 at 01:50:07 UTC, Adam Taylor wrote: Adam Ruppe has an interesting example: What that does is defer the type work to runtime, so a lot of type information is lost there too. The big magic is that the wrapper object is a template, specialized for the compile time type, but once it is used it is still through an interface. This is similar to how the inputRangeObject+InputRange interface work in phobos http://dlang.org/phobos/std_range.html#inputRangeObject Plain interface, templated implementation. I don't really understand your question though
kitchens for sale uk
kitchens for sale uk. Thirty Ex Display Kitchens To Clear. www.exdisplaykitchens1.co.uk £ 595 Each with appliances.Tel 01616-694785 [url=http://www.kitchensforsale.uk.com]kitchens for sale uk[/url]
Re: Destructor/Finalizer Guarantees
On 11/11/14 5:31 PM, Maxime Chevalier-Boisvert wrote: I have a situation where I have a VM (virtual machine) object, and several GCRoot (garbage collector root objects). The GCRoots are structs and will register themselves into a linked list belonging to the VM. I've made it so they unregister themselves in their destructor. This works perfectly well for GC roots which are on the stack. However, recently, I ran into a case where I need GCRoots which are not on the stack. This is where things broke down. The VM object got destroyed before the GCRoots, and when these tried to unregister themselves, they accessed memory which had already been reclaimed (the dead VM). What I want to know is: what guarantees can I expect from destructor behavior? I was thinking that when the VM gets destroyed, it could unregister all of its GCRoots at once. Then, when these are destroyed, they wouldn't try to touch the VM object. However, this only works if I can assume that the GC will first call the destructor on an object, then free the object, that this is done in a predictable order. Am I on the right track, or do I need to rethink this? Short answer, you have no guarantees that references to GC memory still point at valid memory. It is a very sticky problem to deal with. Reference counting and GC don't mix well, because the GC cannot guarantee destruction order. -Steve
Re: Destructor/Finalizer Guarantees
On Tuesday, 11 November 2014 at 22:31:17 UTC, Maxime
Chevalier-Boisvert wrote:
I have a situation where I have a VM (virtual machine) object,
and several GCRoot (garbage collector root objects). The
GCRoots are structs and will register themselves into a
linked list belonging to the VM. I've made it so they
unregister themselves in their destructor. This works perfectly
well for GC roots which are on the stack.
However, recently, I ran into a case where I need GCRoots which
are not on the stack. This is where things broke down. The VM
object got destroyed before the GCRoots, and when these tried
to unregister themselves, they accessed memory which had
already been reclaimed (the dead VM). What I want to know is:
what guarantees can I expect from destructor behavior?
I was thinking that when the VM gets destroyed, it could
unregister all of its GCRoots at once. Then, when these are
destroyed, they wouldn't try to touch the VM object. However,
this only works if I can assume that the GC will first call the
destructor on an object, then free the object, that this is
done in a predictable order. Am I on the right track, or do I
need to rethink this?
Could this work?
class VM {
List gcRootList;
this() {
gcRootList.add(GCRoot.init);
..
to
class VM {
static List[VM*] _gcRootLists;
List* gcRootList;
this() {
_gcRootLists[this] = List.init;
gcRootList = _gcRootLists[this];
gcRootList.add(GCRoot.init);
..
~this() {
_gcRootLists.remove(this);
..
Basically want to make a macro script
/Long/ story short, I want to pretty much make a macro using this
program. I don't really have time to explain in further detail
at the moment, but /no/ macro program out there will do what I'm
trying to do. I want to basically make it so that when I press a
hotkey, it'll send an in game chat message. Here's my code for
the popular program AutoHotKey.
[code]
Numpad0 Numpad1::
Send {k down}
Sleep 1
Send {k up}
SendInput We're losing Alpha{!}
SendInput {Enter}
Return
[/code]
That's a small sample of my script, but the only thing that would
change with the rest of my script would be the message sent and
the keybind to press it.
Basically what it's doing is listening for my hotkey to be
pressed (in this particular example it's numpad 0 + numpad 1 for
the message, We're losing Alpha!, and so on and so forth for
the rest of the numbers.) and then activating the chat button in
game (in this particular examle it's k for team chat), then
sending the actual message as quickly as possible, and sending
it. Works perfectly in BF4, but PB (PunkBuster), the default
anti cheat system that BF4 uses will kick me if the admins have
that setting enabled.
I've been wanting to learn full on programming for a while, and
I've heard a lot of things about D and how it's a pretty good
starting point, and how it has a huge potential to expand you
into anything. Plus it's supposed to be pretty efficient and the
next big thing in the programming world, so there's that.
Just for the record, I don't have a lot of experience with
programming. I've done it years ago (had an instructor for a Boy
Scout Merit Badge class), but I didn't even know which language I
was typing in. I assume it was Python, but I can't be sure.
Whatever I make I want it to be somewhat compatible with Linux
eventually. I just want to start with a binary .exe, but I do
want my code to be compatible with Linux if I choose to compile
it for Linux at a later date. I don't think this should be an
issue, but I just wanted to throw this out there.
I'm not sure which libraries I need for this, but as far as I
know I just need the following:
Keybind listener/hotkey
Keyboard emulating/low level chat producing library
something that /wont/ be picked up as a hack/cheat by /ANYTHING/.
I don't think this should be that hard to make, but D doesn't
really have much documentation out there as far as I can tell, so
I figured this would be the best place to put this.
The sooner the better please. Thanks for any/all help I receive.
Re: alias overloaded function template
On Tuesday, 11 November 2014 at 19:36:12 UTC, Lemonfiend wrote:
D is fine with alias this overloaded function:
---
void foo(int t) {}
void foo(int t, int i) {}
alias bar = foo;
---
But isn't as happy aliasing these function templates:
---
void foo(T)(T t) {}
void foo(T)(T t, int i) {}
alias bar = foo!int;
---
Is there some way/other syntax to make an alias like this work?
Or specify in the alias which function template to use (ie.
alias bar = foo!int(int)).
The problem is not the alias. The error message is about using
the same identifier for two different things:
C:\...\temp_0186F968.d(13,1): Error: declaration foo(T)(T t,
int i) is already defined.
1/ ===
What you seem to forget is that the declarations:
-
void foo(T)(T t) {}
void foo(T)(T t, int i) {}
-
are actually a two **Eponymous template** with the same name:
-
template foo(T){
void foo(T t) {}
}
template foo(T){
void foo(T t, int i) {}
}
-
This produces the same error message:
C:\...\temp_0186F968.d(13,1): Error: declaration foo(T)(T t,
int i) is already defined.
2/ ===
You can make it working by renaming the template name anf by
grouping the members:
-
template hip(T)
{
void bud(T t) {}
void bud(T t, int i) {}
}
alias baz = hip!int.bud;
writeln(typeof(baz).stringof);
// void(int t) or void(int t, int i) if you invert bud order.
-
