Re: Running unit tests from DUB single file packages
On Wednesday, 2 December 2020 at 12:51:11 UTC, drug wrote: [snip] Thanks! Let's see if it gets merged or if a slightly more involved solution is needed. Remake it - https://github.com/dlang/dub/pull/2052 This has more chances to be merged Looks like this got merged and will be part of the newest version, which is great news. Have you checked that it works with dependencies?
Re: BetterC issues with ErupteD Vulkan binding typedef handles
[snip] Forgot to add another question. The mentioned error message is not too helpful in locating the real offended code. Is there a way to get more information or additional hints about the actual cause of the problem?
Re: Flag & byLine confusion.
On Sunday, 20 December 2020 at 15:18:44 UTC, Rekel wrote: By the way, where can I see Flag is (/ will be?) deprecated? It doesn't show in the library reference, however I may be looking in the wrong place. It hasn't been yet.
Re: BetterC issues with ErupteD Vulkan binding typedef handles
On Sunday, 20 December 2020 at 15:52:39 UTC, Adam D. Ruppe wrote: On Sunday, 20 December 2020 at 15:45:59 UTC, ParticlePeter wrote: VkSemaphore[] wait_semaphores = [], // error: TypeInfo required does it still error if you just use = null? they work the same way but might avoid the annoying error. Wow, it does, that was unexpected and unexpectedly hassle free, thanks a lot :-)
Re: BetterC issues with ErupteD Vulkan binding typedef handles
On Sunday, 20 December 2020 at 15:45:59 UTC, ParticlePeter wrote: VkSemaphore[] wait_semaphores = [], // error: TypeInfo required does it still error if you just use = null? they work the same way but might avoid the annoying error.
BetterC issues with ErupteD Vulkan binding typedef handles
Hello,
I am experimenting with betterC and Vulkan through Erupted [0]
binding, but unfortunately I find myself hunting down these kind
of errors:
..\ErupteD\source\erupted\types.d-mixin-77(77,1): Error:
`TypeInfo` cannot be used with -betterC
The issue is with Vulkan type handles. One such error occurs when
a function's parameter list contains an optional slice of such
handles, e.g.:
void queueSubmit(
VkQueuequeue,
VkCommandBuffer[] command_buffers,
VkSemaphore[] wait_semaphores = [], //
error: TypeInfo required
VkPipelineStageFlags[] wait_dest_stage_masks = [], // ok,
not a handle
VkSemaphore[] signal_semaphores = [] //
error: TypeInfo required
) { .. }
A possible workaround which I found is:
VkSemaphore[] wait_semaphores = ( const VkSemaphore[] ).init,
but this feels more like fighting a symptom instead of getting
rid of the cause.
I am wondering if there is a better way to translate these C
typedefs to D:
// from vulkan_core.h [1]
// ...
#define VK_DEFINE_HANDLE(object) typedef struct object##_T*
object;
#if !defined(VK_DEFINE_NON_DISPATCHABLE_HANDLE)
#if defined(__LP64__) || defined(_WIN64) || (defined(__x86_64__)
&& !defined(__ILP32__) ) || defined(_M_X64) || defined(__ia64) ||
defined (_M_IA64) || defined(__aarch64__) ||
defined(__powerpc64__)
#define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef
struct object##_T *object;
#else
#define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef
uint64_t object;
#endif
#endif
// ...
VK_DEFINE_HANDLE(VkQueue)
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore)
// ...
Correspondingly to the C typedefs:
// from erupted/types.d [2]
// ...
enum VK_DEFINE_HANDLE( string name ) = "struct " ~ name ~
"_handle; alias " ~ name ~ " = " ~ name ~ "_handle*;";
version( X86_64 ) {
alias VK_DEFINE_NON_DISPATCHABLE_HANDLE( string name ) =
VK_DEFINE_HANDLE!name;
enum VK_NULL_ND_HANDLE = null;
} else {
enum VK_DEFINE_NON_DISPATCHABLE_HANDLE( string name ) =
"alias " ~ name ~ " = ulong;";
enum VK_NULL_ND_HANDLE = 0uL;
}
// ...
mixin( VK_DEFINE_HANDLE!q{VkQueue} );
mixin( VK_DEFINE_NON_DISPATCHABLE_HANDLE!q{VkSemaphore} );
// ...
I am running building for x64, would anyone know a smoother
betterC approach to these typedefs?
[0] https://github.com/ParticlePeter/ErupteD
[1]
https://github.com/KhronosGroup/Vulkan-Headers/blob/master/include/vulkan/vulkan_core.h
[2]
https://github.com/ParticlePeter/ErupteD/blob/master/source/erupted/types.d
Re: Flag & byLine confusion.
On Sunday, 20 December 2020 at 15:04:29 UTC, Steven Schveighoffer wrote: On 12/20/20 9:07 AM, Rekel wrote: Does this mean other flag yes's will not be accepted? The long and short of it is that Flag is supposed to make you NAME what your flag is for. The idea is to prevent things like: byLine(true); Reading the code, what does "true" mean? You have to look up the documentation to see what it is. And then you might have things like: foo(true, true, false, true); What do all those mean? Instead, you have to name what the flag is for: byLine(KeepTerminator.yes); The Yes/No structs and Flag structs are there to help you name your flag, and have some awkward D way to do this. This will likely all go away in the future with named parameters (deprecating Flag is one of the reasons named parameters were proposed/accepted). I personally avoid Flag in my code because I think it's awkward and cumbersome. -Steve With named parameters, do you refer to python-esque function calls? That makes a lot more sense to me personally, although I'm only just learning D, as I likewise wouldnt use `Number!"Wheels".4` for a function call. By the way, where can I see Flag is (/ will be?) deprecated? It doesn't show in the library reference, however I may be looking in the wrong place.
Re: Flag & byLine confusion.
On 12/20/20 9:07 AM, Rekel wrote: Does this mean other flag yes's will not be accepted? The long and short of it is that Flag is supposed to make you NAME what your flag is for. The idea is to prevent things like: byLine(true); Reading the code, what does "true" mean? You have to look up the documentation to see what it is. And then you might have things like: foo(true, true, false, true); What do all those mean? Instead, you have to name what the flag is for: byLine(KeepTerminator.yes); The Yes/No structs and Flag structs are there to help you name your flag, and have some awkward D way to do this. This will likely all go away in the future with named parameters (deprecating Flag is one of the reasons named parameters were proposed/accepted). I personally avoid Flag in my code because I think it's awkward and cumbersome. -Steve
Re: Flag & byLine confusion.
On Sunday, 20 December 2020 at 14:07:56 UTC, Rekel wrote: The template parameter serves to make Flag!"foo" a distinct type from Flag!"bar". Does this mean other flag yes's will not be accepted? Yes. https://dlang.org/spec/operatoroverloading.html#dispatch Also regarding the other examples given, why does Phobos use templating so heavily, in situation in which I am totally confused as to why generics would be necessary. I seem to be totally confused as to how this template system works. It was introduced as a kind of generic, like in Java, but things like 'string s' seem to me like parameters. Java's generics are good for what they do, bolted onto an existing language in a non-breaking way as they were, but they are a pale shadow of a real metaprogramming system. D's template metaprogramming is not anything like Java generics. It's more akin to C++ templates---much more powerful than what Java offers you. If Java's generics are all you know, then breaking through your confusion and answering your questions is going to require more than a forum post. You'll want to read up and get some hands on. I have an introductory post on the D blog which is the first in a series (that I'll have finally have time to continue in the new year). It goes over the very, very basics: https://dlang.org/blog/2020/07/31/the-abcs-of-templates-in-d/ After you read that introduction, you should look into Ali's coverage of templates in 'Programming in D': http://ddili.org/ders/d.en/ When you're ready for more, Phillippe Sigaud's tutorial is excellent (though several old, it's still mostly relevant): https://github.com/PhilippeSigaud/D-templates-tutorial
Re: If statements and unused template parameters in Phobos documentation
On Sunday, 20 December 2020 at 13:58:00 UTC, Max Haughton wrote: The if is a template constraint. Ah sorry! I must have missed that part of the dlang tour. (https://tour.dlang.org/tour/en/gems/template-meta-programming) Thanks a lot!
Re: Flag & byLine confusion.
Thanks for all the help! This makes it make a lot more sense now,
I'm surprised it's not part of the dlang tour.
The template parameter serves to make Flag!"foo" a distinct
type from Flag!"bar".
Does this mean other flag yes's will not be accepted?
https://dlang.org/spec/operatoroverloading.html#dispatch
Also regarding the other examples given, why does Phobos use
templating so heavily, in situation in which I am totally
confused as to why generics would be necessary.
I seem to be totally confused as to how this template system
works. It was introduced as a kind of generic, like in Java, but
things like 'string s' seem to me like parameters.
For example;
```
class C
{
void opDispatch(string s)(int i)
{
writefln("C.opDispatch('%s', %s)", s, i);
}
}
```
I'm pretty sure I'm confusing something, though I don't see the
point of using this instead of something like 'opDispatch(string
s, int i)`?
I also came across a similar thing in the File.byLine
documentation.
(https://dlang.org/library-prerelease/std/stdio/file.by_line.html)
Re: If statements and unused template parameters in Phobos documentation
On Sunday, 20 December 2020 at 13:51:08 UTC, Rekel wrote: I found a lot of the Phobos documentation to contain template arguments and if statements that made no sense to me, for example: ``` uint readf(alias format, A...) ( auto ref A args ) if (isSomeString!(typeof(format))); uint readf(A...) ( scope const(char)[] format, auto ref A args ); ``` https://dlang.org/library/std/stdio/file.readf.html From stdio.readf & stdio.File.readf. I'm assuming this is some kind of template, but often it seems there are more parameters in the first '()' part than are ever given. Am I missing something? Additionally, what is that if statement for? It precedes nothing. The if is a template constraint.
If statements and unused template parameters in Phobos documentation
I found a lot of the Phobos documentation to contain template arguments and if statements that made no sense to me, for example: ``` uint readf(alias format, A...) ( auto ref A args ) if (isSomeString!(typeof(format))); uint readf(A...) ( scope const(char)[] format, auto ref A args ); ``` https://dlang.org/library/std/stdio/file.readf.html From stdio.readf & stdio.File.readf. I'm assuming this is some kind of template, but often it seems there are more parameters in the first '()' part than are ever given. Am I missing something? Additionally, what is that if statement for? It precedes nothing.
Re: Getting started with graphqld
On Friday, 18 December 2020 at 02:46:32 UTC, Trustee wrote: On Thursday, 17 December 2020 at 14:49:42 UTC, evilrat wrote: On Tuesday, 15 December 2020 at 16:25:29 UTC, Trustee wrote: connect a basic vibe-d app to a graphql backend. umm, what? Did you mean write graphql backend using vibe.d? Yes. But more so, I want to learn the ins and outs of the graphqld package. What's contained, what isn't (in terms of what functionality available and/or possible - e.g. client gen???, xSQL gen), what to build to add to complement/contribute to the package. The first phase, docs. I have already begun working through the code and it's beginning to make sense. To be fair it's more about my fluency in D than the package itself. I haven't been coding for a while so it gets kinda rusty. I'm also familiar with GraphQL in Node.js. The issue I find with graphqld package is their selection of terminologies (+ how the code is written). The code is also a test so it uses all the features of the package and not necessarily the essentials. So it will take some time to figure it out...including reading the original source code of the package. My current understanding is it uses vibe.d to serve some static data. It does some validation of schema among other things and since the example meant as a development guinea pig, it uses all the API spread throughout the code. I've not given it much time to filter those out myself. Will take a look once more after watching his DConf video about itsomething about all spreadsheets must die. Any help would be appreciated though. Hit me up in the dlang discord... @aberba
Re: Alias woes
On Saturday, 19 December 2020 at 07:41:09 UTC, SealabJaster wrote: ... The nesting behavior is indeed intentional: https://dlang.org/spec/template.html#implicit-nesting But I still assume the assignment to a function is also a bug, so I'll file that if it hasn't been already (unless for some very strange reason it's not a bug?). Still though, this is very annoying behavior when you consider an example such as: https://godbolt.org/z/9nWWxa Alas :(
