Re: mixin template's alias parameter ... ignored ?
On Sunday, 11 July 2021 at 05:54:48 UTC, Ali Çehreli wrote:
The only way that I know is to take a string parameter and use
it with a string mixin:
Yes, that I tried, but the structure has a lot of lines of codes
and so it is impractical and of course it will turn out difficult
to debug.
Since this seems to be a dead-end I did reshuffle some things
around:
```d
/// for illustration purposes only:
alias stringUTF08 = string; /// = immutable(char )[];
alias stringUTF16 = dstring; /// = immutable(dchar)[];
alias stringUTF32 = wstring; /// = immutable(wchar)[];
alias stringUGC08 = gudtUGC!(stringUTF08);
alias stringUGC16 = gudtUGC!(stringUTF16);
alias stringUGC32 = gudtUGC!(stringUTF32);
public struct gudtUGC(typeStringUTF) {
typeStringUTF whatever;
... lots of functions using typeStringUTF here
}
void main() {
version (useUTF08) { stringUGC08 lugcSequence3 =
stringUGC08(r"..."c); }
version (useUTF16) { stringUGC16 lugcSequence3 =
stringUGC16(r"..."d); }
version (useUTF32) { stringUGC32 lugcSequence3 =
stringUGC32(r"..."w); }
}
```
It works.
Thanks Ali :) !
Re: mixin template's alias parameter ... ignored ?
On 7/10/21 10:20 PM, someone wrote:
> mixin template templateUGC (
> typeStringUTF,
> alias lstrStructureID
> ) {
>
> public struct lstrStructureID {
The only way that I know is to take a string parameter and use it with a
string mixin:
mixin template templateUGC (
typeStringUTF,
string lstrStructureID
) {
mixin("public struct " ~ lstrStructureID ~ q{
{
typeStringUTF whatever;
}
});
}
mixin templateUGC!(string, "gudtUGC08");
mixin templateUGC!(dstring, "gudtUGC16");
mixin templateUGC!(wstring, "gudtUGC32");
void main() {
gudtUGC32 something;
}
Ali
mixin template's alias parameter ... ignored ?
```d
mixin template templateUGC (
typeStringUTF,
alias lstrStructureID
) {
public struct lstrStructureID {
typeStringUTF whatever;
}
}
mixin templateUGC!(string, "gudtUGC08");
mixin templateUGC!(dstring, "gudtUGC16");
mixin templateUGC!(wstring, "gudtUGC32");
void main() {
gudtUGC32 something; /// Error: undefined identifier
`gudtUGC32`
}
```
I cannot manage to get this right; not even with:
```d
public struct mixin(lstrStructureID) { ... }
```
because the argument seems to require a complete statement.
TDPL book and __traits(compiles...) snippet
In section 6.2 of The D Programming Language it talks about how
the compiler will try and tell if you are going to use a null
reference. It gives this code snippet below to demonstrate that.
But with DMD v2.096.1-dirty I am getting that the compiler thinks
the code is OK. With a "!" the assert fails.
class A { int x; }
A a;
assert(!__traits(compiles, a.x = 5));
Re: assert(false) and GC
On Saturday, 10 July 2021 at 16:32:30 UTC, Mathias LANG wrote: On Saturday, 10 July 2021 at 01:38:06 UTC, russhy wrote: On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer wrote: I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. -Steve i think you are right Try to use `@nogc` instead, it'll show you it does not allocate. A caveat though: A failing assert used to allocate before v2.097.0 (the latest version), it does not anymore. However, as your test captures all GC allocation, it likely triggers while the runtime is initializing. yes you are right, i forgot to add extern(C) in main, so the allocation happens in the runtime initialization and not for the assert i apologies for the confusion i caused
Re: how to make D program footprint smaller ?
On Friday, 9 July 2021 at 03:07:04 UTC, dangbinghoo wrote: as questioned in the previous thread, I need to find out something like `--as-needed` options available for D. You are probably looking for the [-i](https://dlang.org/dmd-osx.html#switch-i%5B) compiler option. As far as I know `dub` is not devised to work with that, so making use of it can be finicky. I have managed to get it to work on a `sourceLibrary` that we control, not sure how applicable it is on a third party package. — Bastiaan.
Re: Trivial simple OpenGl working example
On Saturday, 10 July 2021 at 12:41:19 UTC, Виталий Фадеев wrote: On Saturday, 10 July 2021 at 08:36:07 UTC, Danny Arends wrote: On Thursday, 8 July 2021 at 13:51:51 UTC, Виталий Фадеев wrote: [...] OpenGL is being replaced by vulcan, just to plug my little project: http://github.com/DannyArends/CalderaD Pretty beafy, but well vulkan is a lot more verbose compared to OpenGL Thank, Danny Arends! I see you. I got error: # glslc app/src/main/assets/data/shaders/wavefront.vert -o app/src/main/assets/data/shaders/vert.spv # glslc app/src/main/assets/data/shaders/wavefront.frag -o app/src/main/assets/data/shaders/frag.spv # dub Performing "debug" build using /usr/bin/dmd for x86_64. bindbc-loader 0.3.2: target for configuration "yesBC" is up to date. bindbc-sdl 0.21.4: target for configuration "dynamicBC" is up to date. calderad ~master: building configuration "default"... Running pre-build commands... /bin/sh: 1: glslc.exe: not found Command failed with exit code 127: glslc.exe app/src/main/assets/data/shaders/wavefront.vert -o app/src/main/assets/data/shaders/vert.spv Just disable shader compilation using dub, the shader only needs to be compiled once. Since you're on linux it fails to execute glslc.exe (the windows executable). If you compiled them yourself you can remove it from dub prebuild commands
Re: assert(false) and GC
On Saturday, 10 July 2021 at 01:38:06 UTC, russhy wrote: On Saturday, 10 July 2021 at 01:23:26 UTC, Steven Schveighoffer wrote: I think it's the throwing/catching of the `Throwable` that is allocating. But I don't know from where the allocation happens. -Steve i think you are right Try to use `@nogc` instead, it'll show you it does not allocate. A caveat though: A failing assert used to allocate before v2.097.0 (the latest version), it does not anymore. However, as your test captures all GC allocation, it likely triggers while the runtime is initializing.
Re: Can I get the time "Duration" in "nsecs" acurracy?
On 7/9/21 11:28 PM, rempas wrote: > So it's an OS thing? Don't listen to me on this. :) A quick search yesterday made me believe you need kernel support as well. Even if so, I would imagine modern kernel on modern hardware should work. Ali
Re: Trivial simple OpenGl working example
On Saturday, 10 July 2021 at 08:36:07 UTC, Danny Arends wrote: On Thursday, 8 July 2021 at 13:51:51 UTC, Виталий Фадеев wrote: Hi! I searching trivial simple D/OpenGL working in 2021 year example. It may be triangle. It may be based on any library: SDL, GLFW, Derelict, etc. Can you help me ? OpenGL is being replaced by vulcan, just to plug my little project: http://github.com/DannyArends/CalderaD Pretty beafy, but well vulkan is a lot more verbose compared to OpenGL Thank, Danny Arends! I see you. I got error: # glslc app/src/main/assets/data/shaders/wavefront.vert -o app/src/main/assets/data/shaders/vert.spv # glslc app/src/main/assets/data/shaders/wavefront.frag -o app/src/main/assets/data/shaders/frag.spv # dub Performing "debug" build using /usr/bin/dmd for x86_64. bindbc-loader 0.3.2: target for configuration "yesBC" is up to date. bindbc-sdl 0.21.4: target for configuration "dynamicBC" is up to date. calderad ~master: building configuration "default"... Running pre-build commands... /bin/sh: 1: glslc.exe: not found Command failed with exit code 127: glslc.exe app/src/main/assets/data/shaders/wavefront.vert -o app/src/main/assets/data/shaders/vert.spv
Re: Can I get the time "Duration" in "nsecs" acurracy?
On Saturday, 10 July 2021 at 01:11:28 UTC, Steven Schveighoffer wrote: You can get better than hnsecs resolution with `core.time.MonoTime`, which can support whatever the OS supports. However, `Duration` and `SysTime` are stored in hnsecs for a very specific reason -- range. Simply put, if you have a 64-bit integer, and you picked nanoseconds as the unit, you can store only 585 years of range. 10 ns gives you 5850 years, and 100 ns gives you 58k years. That should be good enough for all but the most esoteric calculations (given that a `Duration` is signed, this gives a range of roughly -29k years to 29k years). Note also that hnsecs is the base unit for Windows high precision clocks, though their epoch is year 1600 instead of year 0. Nice summary. hnsecs is a little weird but defensible given the range argument. Down the road we might add a nanosecond timeline abstraction based on TAI with zero set to 1972 (when UTC was aligned with TAI IIUC). Range issues could be addressed by animating the long dormant cent. Any precision issues could be handled with fixed point pairs. Doubles across the same timeline would work for casual applications.
Re: Trivial simple OpenGl working example
On Thursday, 8 July 2021 at 13:51:51 UTC, Виталий Фадеев wrote: Hi! I searching trivial simple D/OpenGL working in 2021 year example. It may be triangle. It may be based on any library: SDL, GLFW, Derelict, etc. Can you help me ? OpenGL is being replaced by vulcan, just to plug my little project: http://github.com/DannyArends/CalderaD Pretty beafy, but well vulkan is a lot more verbose compared to OpenGL
