Re: Examples Wanted: Usages of "body" as a Symbol Name
On Wednesday, 5 October 2016 at 02:11:14 UTC, Meta wrote:
I'm currently writing up a DIP to propose removing `body` as a
keyword to allow it to be used for variable names, functions,
etc. I'm looking for examples and contexts where `body` would
normally be used as a variable, function name, alias, etc. This
is what I have come up with off the top of my head:
- In web programming where "body" is a required tag in any
valid HTML document. Ex:
- It is a name commonly used for XML tags and/or attributes
- Physics simulations as well in astronomical contexts
("planetary bodyies", etc.)
- Video games, such as referring to the player character's body
i think you covered most of the cases. as for me, it is more than
enough. as for my cases, physics engines suffers most: it is *so*
natural to use "body" field/variable there... and so annoying to
always add ugly "_" suffix.
Re: uuid.d
On Wednesday, 5 October 2016 at 02:34:52 UTC, Manu wrote: Sure, I can always work-around problems locally. Eh, I tend to stop at "works for me" so I can't do much else. They'd prolly accept a PR adding the other guids to the druntime file though without real hassle, though I wonder if they should actually be listed there as they are now, or if they should be redefined to be `extern` so it always loads the actual symbol off the system dll. I imagine extern is the way to go... but I don't know why they didn't do it that way originally. Are all those guids in the system libs?
Re: uuid.d
On Wednesday, 5 October 2016 at 02:35:27 UTC, Manu wrote: So, phobos64.lib includes druntime? They're not built separately? They are built separately, but bundled together at the last step for distribution.
Re: debugging mixins
On Tuesday, 4 October 2016 at 01:59:11 UTC, Stefan Koch wrote: On Tuesday, 4 October 2016 at 01:20:01 UTC, Manu wrote: On 4 October 2016 at 04:21, Stefan Koch via Digitalmars-d wrote: On Monday, 3 October 2016 at 15:23:40 UTC, Jonathan Marler wrote: Yes, having the mixins expanded without the surrounding code would make it difficult to debug in some cases. Maybe generating the entire source with the expanded mixins is another option? mycode.d obj/mycode_processed.d That was my intention. Maybe this idea could also be expanded to template instantiation? Oh yes. it is not that more much work :) A small update on this. The POC works rather well ... Except for cases of massive template recursion. (binderoo and most of std.traits) In such cases a stack overflow occurs inside the prettyPrinter. I am trying to find a work-around.
Re: uuid.d
On 5 October 2016 at 12:12, Adam D. Ruppe via Digitalmars-d wrote: > On Wednesday, 5 October 2016 at 01:57:35 UTC, Manu wrote: >> >> it's saying they're already defined in phobos64.lib... wtf? >> I checked std/uuid.d and there's nothing of the sort defined in >> there... > > > They are in the druntime src, core.sys.windows.uuid > > https://github.com/dlang/druntime/blob/master/src/core/sys/windows/uuid.d So, phobos64.lib includes druntime? They're not built separately?
Re: uuid.d
On 5 October 2016 at 12:12, Adam D. Ruppe via Digitalmars-d wrote: > On Wednesday, 5 October 2016 at 01:57:35 UTC, Manu wrote: >> >> it's saying they're already defined in phobos64.lib... wtf? >> I checked std/uuid.d and there's nothing of the sort defined in >> there... > > > They are in the druntime src, core.sys.windows.uuid > > https://github.com/dlang/druntime/blob/master/src/core/sys/windows/uuid.d > >> So, dxguid.lib appears to be mutually exclusive with phobos64.lib, except >> that phobox64.lib is incomplete... I can't link. > > > I'm not sure what the best solution is, but one you could do is just take > the missing ones and define them in your own file, then link with phobos but > not with dxguid. Sure, I can always work-around problems locally. But my point is, it's not okay how it is.
Re: Ranges and Take
On Wednesday, October 05, 2016 00:10:39 Jacob via Digitalmars-d wrote: > Having access to iterators would solve the problem here I think. > But everything is ranges and that wouldn't entirely fit. For a > linked list though, you can create a range from a single > iterator. The implementation of DList's Range is pretty much two > iterators. Oh well, have to implement my own anyways I guess, > since DList uses the garbage collector. A replacement for std.container is in the works, but who knows when that will be done (or whether the result will really be what you want anyway). In the interim, I'd recommend checking out http://code.dlang.org/packages/emsi_containers - Jonathan M Davis
Re: Challenge
On Wednesday, October 05, 2016 11:20:44 Manu via Digitalmars-d wrote:
> > While you're at it, might I suggest also adding std.traits.isProperty?
> >
> > Something like:
> > template isProperty(T, string member)
> > {
> >
> > import std.meta : AliasSeq;
> > import std.traits : FunctionTypeOf;
> > alias sym = AliasSeq!(__traits(getMember, T, member))[0];
> > enum isProperty = !is(typeof(sym) == function) &&
> >
> > is(FunctionTypeOf!(typeof(&sym)) == function);
> > }
>
> Why this AliasSeq business? That line is rather an abomination... why
> are all these horrible expressions popping up as recommendations
> nowadays?
The AliasSeq muck is there because for some reason you can't alias the
result of __traits, so doing something like
alias sym = __traits(getMember, T, member);
isn't legal. So, this has nothing to do with a recommendation of best
practice and everything to do with an annoying bug.
https://issues.dlang.org/show_bug.cgi?id=7804
It _is_ however recommended to use __traits(getMember, T, member) over
manually building it with strings with something like T.stringof ~ "." ~
member, because the string manipulation falls about in corner cases (e.g. it
could result in a symbol conflict). It's just that then has the unfortunate
side effect of requiring AliasSeq because of the bug.
- Jonathan M Davis
Re: uuid.d
On Wednesday, 5 October 2016 at 01:57:35 UTC, Manu wrote: it's saying they're already defined in phobos64.lib... wtf? I checked std/uuid.d and there's nothing of the sort defined in there... They are in the druntime src, core.sys.windows.uuid https://github.com/dlang/druntime/blob/master/src/core/sys/windows/uuid.d So, dxguid.lib appears to be mutually exclusive with phobos64.lib, except that phobox64.lib is incomplete... I can't link. I'm not sure what the best solution is, but one you could do is just take the missing ones and define them in your own file, then link with phobos but not with dxguid.
Examples Wanted: Usages of "body" as a Symbol Name
I'm currently writing up a DIP to propose removing `body` as a
keyword to allow it to be used for variable names, functions,
etc. I'm looking for examples and contexts where `body` would
normally be used as a variable, function name, alias, etc. This
is what I have come up with off the top of my head:
- In web programming where "body" is a required tag in any valid
HTML document. Ex:
- It is a name commonly used for XML tags and/or attributes
- Physics simulations as well in astronomical contexts
("planetary bodyies", etc.)
- Video games, such as referring to the player character's body
uuid.d
I have this weird link error going on: 1>dxguid.lib(dxguid.obj) : error LNK2005: IID_IDirectSoundCapture already defined in phobos64.lib(uuid.obj) 1>dxguid.lib(dxguid.obj) : error LNK2005: IID_IDirectSoundCaptureBuffer already defined in phobos64.lib(uuid.obj) 1>dxguid.lib(dxguid.obj) : error LNK2005: DPLPROPERTY_MessagesSupported already defined in phobos64.lib(uuid.obj) 1>dxguid.lib(dxguid.obj) : error LNK2005: DPLPROPERTY_LobbyGuid already defined in phobos64.lib(uuid.obj) 1>dxguid.lib(dxguid.obj) : error LNK2005: DPLPROPERTY_PlayerGuid already defined in phobos64.lib(uuid.obj) 1>dxguid.lib(dxguid.obj) : error LNK2005: DPLPROPERTY_PlayerScore already defined in phobos64.lib(uuid.obj) 1>dxguid.lib(dxguid.obj) : error LNK2005: IID_IDirectSoundNotify already defined in phobos64.lib(uuid.obj) etc, for pages and pages... I expect to find these symbols in dxguid.lib, so I link the lib, and it's saying they're already defined in phobos64.lib... wtf? I checked std/uuid.d and there's nothing of the sort defined in there... I can't find any mention of these symbols anywhere in the phobos source. Can any phobos dev's suggest how this mountain of guid symbols might find its way into phobos? I figured "okay, I guess I don't need to link dxguid.lib", so I didn't, and it did resolve 99% of the symbols... except I have 4 left: 2>error LNK2001: unresolved external symbol IID_IDirectInput8W 2>error LNK2001: unresolved external symbol IID_IDirectSoundBuffer8 2>error LNK2001: unresolved external symbol WKPDID_D3DDebugObjectName 2>error LNK2001: unresolved external symbol WKPDID_D3DDebugObjectName So, dxguid.lib appears to be mutually exclusive with phobos64.lib, except that phobox64.lib is incomplete... I can't link.
Re: Challenge
On 4 October 2016 at 22:48, Manu wrote:
> On 4 October 2016 at 14:40, Jonathan M Davis via Digitalmars-d
> wrote:
>> On Tuesday, October 04, 2016 14:24:59 Manu via Digitalmars-d wrote:
>>> On 4 October 2016 at 12:30, Jonathan M Davis via Digitalmars-d
>>>
>>> wrote:
>>> > On Tuesday, October 04, 2016 11:13:36 Manu via Digitalmars-d wrote:
>>> >> I'm feeling John's solution is a little bit simpler. But nice work,
>>> >> thanks!
>>> >
>>> > So, it is. LOL. I'd actually glanced over that post while I was in the
>>> > middle of getting my version to work, and I read it too quickly, because I
>>> > understood that it had just solved the property problem and that it didn't
>>> > work for all cases. I'll have to update my PR. Though his code does make
>>> > the mistake of doing
>>> >
>>> > mixin(`alias mem = T.` ~ member ~ `;`);
>>> >
>>> > rather than doing something like
>>> >
>>> > alias mem = AliasSeq!(__traits(getMember, T, member))[0];
>>> >
>>> > which means that there are some cases where it won't work properly. The
>>> > core logic is simpler though, which is definitely a plus.
>>>
>>> Make that change in your PR :)
>>
>> I already updated it and was actually able to make it slightly simpler than
>> John's example (as far as I can tell, FunctionTypeOf is only needed in the
>> case where the address is taken).
>>
>>> I think the PR is important. It's not obvious how to do this, and it's
>>> very useful. I was astonished it's not already there.
>>
>> Yeah. I ran into a need for something similar recently, but my
>> implementation at the time wasn't as thorough, since it just used offsetof
>> to do the check (though in my case, I think that was enough). Getting it
>> completely right is surprisingly difficult.
>>
>> I was also surprised that while we have quite a few __traits for functions,
>> they're severely lacking for variables (e.g. I was looking for the variable
>> equivalent of __traits(isStaticFunction, ...), and there is no such beast).
>> For that matter, even testing whether something is a variable is
>> surprisingly difficult.
>>
>> - Jonathan M Davis
>
> While you're at it, might I suggest also adding std.traits.isProperty?
> Something like:
>
> template isProperty(T, string member)
> {
> import std.meta : AliasSeq;
> import std.traits : FunctionTypeOf;
> alias sym = AliasSeq!(__traits(getMember, T, member))[0];
> enum isProperty = !is(typeof(sym) == function) &&
> is(FunctionTypeOf!(typeof(&sym)) == function);
> }
Why this AliasSeq business? That line is rather an abomination... why
are all these horrible expressions popping up as recommendations
nowadays?
Re: Ranges and Take
Having access to iterators would solve the problem here I think. But everything is ranges and that wouldn't entirely fit. For a linked list though, you can create a range from a single iterator. The implementation of DList's Range is pretty much two iterators. Oh well, have to implement my own anyways I guess, since DList uses the garbage collector.
Re: A whirlwind tour of the research literature on garbage collection.
On Tuesday, 4 October 2016 at 20:56:42 UTC, John Carter wrote: https://eschew.wordpress.com/2016/09/02/summarizing-gc/ Maybe of interest to the GC folks, some discussion of what the Rust and Go guys are up to as well. Some cool resources right there. Thanks.
Re: Cannot access template name from within template
On Tuesday, 4 October 2016 at 22:43:21 UTC, Andrei Alexandrescu wrote: On 10/04/2016 06:03 PM, Andrej Mitrovic wrote: template TemplateOf(T) Have you forgotten you submitted this to phobos? :o) -- Andrei I forgot about that template. But that wasn't me: https://github.com/dlang/phobos/pull/1884 :) I added isInstanceOf https://github.com/dlang/phobos/commit/e02593090a909948183921f6f00039ce3f37acff
Re: Cannot access template name from within template
On 10/04/2016 06:03 PM, Andrej Mitrovic wrote: template TemplateOf(T) Have you forgotten you submitted this to phobos? :o) -- Andrei
Re: Cannot access template name from within template
On Monday, 3 October 2016 at 22:28:46 UTC, Andrei Alexandrescu
wrote:
Any known workaround?
If you're ok with the hacky approach:
-
import std.algorithm;
import std.conv;
/// these are in std.traits but private for whatever reason
alias Identity(alias A) = A;
alias parentOf(alias sym) = Identity!(__traits(parent, sym));
alias parentOf(alias sym : T!Args, alias T, Args...) =
Identity!(__traits(parent, T));
/// alias itself to the symbol of template instance T
template TemplateOf(T)
{
enum name = T.stringof;
// strip everything after '!' (instantiation args)
enum unqual_name = name.until!(a => a == '!').to!string;
mixin("alias TemplateOf = parentOf!T." ~ unqual_name ~ ";");
}
template SomethingCool(alias X)
{
pragma(msg, X.stringof); // sanity check
alias Y = X!int;
}
struct MyStruct(T)
{
alias A = SomethingCool!(TemplateOf!MyStruct);
}
struct Outer
{
struct Nested(T)
{
alias A = SomethingCool!(TemplateOf!Nested);
}
}
void main ( )
{
alias MyStruct!int X;
alias Outer.Nested!int Y;
}
-
A whirlwind tour of the research literature on garbage collection.
https://eschew.wordpress.com/2016/09/02/summarizing-gc/ Maybe of interest to the GC folks, some discussion of what the Rust and Go guys are up to as well.
Re: [OT] Stackless fibers/coroutines
On 2016-09-26 16:31, Nick Sabalausky wrote: I don't know about async/await, because all my C# work was with versions of C# that predated those. But as for C#'s yield functions, yes, that's my understanding: It's hidden magic automatically inserted by the compiler. This talk [1] from cppcon 2016, C++ Coroutines: Under the covers, gave some really nice insight how they implement coroutines in C++. It basically works like in Protothreads. The secret how the state is handled, I believe, is that all coroutines need to return a specific type that, I'm guessing, contains the state. Like generator or task. This return value is later used to resume the function. Directly calling the coroutine again will start a new invocation with a new state. I'm guessing it works the same in C# [2]. The state is hidden in the IEnumerable that is returned, which will later be used in a foreach loop which will resume the coroutine. [1] https://www.youtube.com/watch?v=bzAbe1VzhKk&index=51&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH [2] https://msdn.microsoft.com/en-us/library/9k7k7cf0.aspx -- /Jacob Carlborg
Re: Ranges and Take
On Tuesday, October 04, 2016 14:22:51 Jacob via Digitalmars-d wrote: > Currently some implementations rely on the struct Take from > std.range to obtain certain functionality. I think this is a bit > flawed, as it isn't generic enough. As such you end being locked > to this "Take" structure. Which means you can't define your own > implementation if needed. > > > https://github.com/dlang/phobos/blob/v2.071.2/std/container/dlist.d#L649 > > > It is used here in DList in "linearRemove". There is a function > "tail" which implements getting a range for the last few > elements. But it is a bit inefficient as it first has to go > through every single element from the front. At least in the case > of a linked list. So maybe I want to implement my own "TailTake", > that now means defining a new overload for "linearRemove" in > DList. Then not only that there are already other functions in > std.range that do define their on constructs, "takeOne()" for > example does this. So that function can't be used with DList, and > so forth. The problem is that the range type has to be known for the *remove functions to work. It needs to either be the original range or one that wraps the original range in a known way. If it were an arbitrary range, there would be no way to know which elements in the range corresponded to which elements in the container - or whether the elements in the range had anything to do with the container at all. It really doesn't work for the *remove functions to take arbitrary ranges, even if they wrap the original range from the container. There needs to be a standard list of ranges that the *remove functions know about and know how to handle, and the types that come from the take* functions are the obvious choice. It may be that we need additional take* functions for specific cases that aren't currently covered, but it really isn't going to work to try and accept arbitrary ranges. That's actually part of why we need better *remove functions that don't use ranges at all. This is one of the few areas where ranges really don't work as well as iterators. But as to a take* function that takes from the end, I don't see how we could do that with the current range API - at least not and get a range out of it. If you have a random access range, then either it supports slicing (in which case you can just slice it), or it would be pretty trivial to create a version of take that did the slicing for you (though really, that's an argument for requiring that random access ranges just support slicing). So, random access ranges really _should_ work right now without needing any special take* functions. It's bidirectional ranges that would need some sort of takeBack or takeTail. The problem is that while it would be trivial enough to indicate that popBack only has n elements to pop off, for takeTail to actually result in a range, it would need to give you access to the first element in that range, and it can't do that, because the underlying range isn't random access. And there's no such thing as a range that only has back/popBack and not front/popFront. So, what we'd end up with would be some sort of struct that wasn't actually a range that the *remove functions recognized but which would be pretty much useless outside of that, because it wouldn't be an actual range. An alternative would be a *remove function that was supposed to specifically remove elements that were at the end of the range, and it took an argument for the number of elements. But that's not altogether pretty either. Really, this is not a pretty problem. Using take* like we do now was the best that we came up with to make it so that we didn't have to remove every element in the range from the container, but it requires declaring multiple *remove functions for each of the different versions of take*, and it's not exactly pretty. But no one has come up with a better solution yet. The "cursors" that Steven uses in dcollections might solve the problem, because they become range/iterator hybrids, but Andrei is against using them in Phobos. I'm not very familiar with their details though. So, a better solution would definitely be great, but I don't see how it could possibly work for a container's *remove function to accept arbitrary ranges even if they wrap a range that originates from the container. - Jonathan M Davis
Ranges and Take
Currently some implementations rely on the struct Take from std.range to obtain certain functionality. I think this is a bit flawed, as it isn't generic enough. As such you end being locked to this "Take" structure. Which means you can't define your own implementation if needed. https://github.com/dlang/phobos/blob/v2.071.2/std/container/dlist.d#L649 It is used here in DList in "linearRemove". There is a function "tail" which implements getting a range for the last few elements. But it is a bit inefficient as it first has to go through every single element from the front. At least in the case of a linked list. So maybe I want to implement my own "TailTake", that now means defining a new overload for "linearRemove" in DList. Then not only that there are already other functions in std.range that do define their on constructs, "takeOne()" for example does this. So that function can't be used with DList, and so forth.
Re: Challenge
On 4 October 2016 at 14:40, Jonathan M Davis via Digitalmars-d
wrote:
> On Tuesday, October 04, 2016 14:24:59 Manu via Digitalmars-d wrote:
>> On 4 October 2016 at 12:30, Jonathan M Davis via Digitalmars-d
>>
>> wrote:
>> > On Tuesday, October 04, 2016 11:13:36 Manu via Digitalmars-d wrote:
>> >> I'm feeling John's solution is a little bit simpler. But nice work,
>> >> thanks!
>> >
>> > So, it is. LOL. I'd actually glanced over that post while I was in the
>> > middle of getting my version to work, and I read it too quickly, because I
>> > understood that it had just solved the property problem and that it didn't
>> > work for all cases. I'll have to update my PR. Though his code does make
>> > the mistake of doing
>> >
>> > mixin(`alias mem = T.` ~ member ~ `;`);
>> >
>> > rather than doing something like
>> >
>> > alias mem = AliasSeq!(__traits(getMember, T, member))[0];
>> >
>> > which means that there are some cases where it won't work properly. The
>> > core logic is simpler though, which is definitely a plus.
>>
>> Make that change in your PR :)
>
> I already updated it and was actually able to make it slightly simpler than
> John's example (as far as I can tell, FunctionTypeOf is only needed in the
> case where the address is taken).
>
>> I think the PR is important. It's not obvious how to do this, and it's
>> very useful. I was astonished it's not already there.
>
> Yeah. I ran into a need for something similar recently, but my
> implementation at the time wasn't as thorough, since it just used offsetof
> to do the check (though in my case, I think that was enough). Getting it
> completely right is surprisingly difficult.
>
> I was also surprised that while we have quite a few __traits for functions,
> they're severely lacking for variables (e.g. I was looking for the variable
> equivalent of __traits(isStaticFunction, ...), and there is no such beast).
> For that matter, even testing whether something is a variable is
> surprisingly difficult.
>
> - Jonathan M Davis
While you're at it, might I suggest also adding std.traits.isProperty?
Something like:
template isProperty(T, string member)
{
import std.meta : AliasSeq;
import std.traits : FunctionTypeOf;
alias sym = AliasSeq!(__traits(getMember, T, member))[0];
enum isProperty = !is(typeof(sym) == function) &&
is(FunctionTypeOf!(typeof(&sym)) == function);
}
automatically adding rust/cargo libs as dependencies in dub
in how far would it be possible to integrate and statically link rust libraries within dub projects? this could give a huge boost to the library ecosystem if it would be as easy (or easier) as statically linking against other .a files.
