Re: Alias woes
On Thursday, 17 December 2020 at 22:06:00 UTC, SealabJaster wrote:
...
Well, at least I understand why the context pointer exists now.
If you were to add a `pragma(msg, __FUNCTION__)` into either of
the templated functions, you'd get the following output.
```
example.C.doShizz!(a).doShizz
example.C.staticShizz!(a).staticShizz
```
Where `example` is likely the name of the module in Godbolt.
But then there's the `.C.` part, which is the parent type for the
alias being passed into the templated functions.
So essentially, the compiler is rewriting `doShizz!(C.a)` as
something like?:
```
struct C
{
int a;
template doShizz(alias T = a)
{
void doShizz(ref string a){...}
}
}
```
Weird, and annoying. Especially since the compiler still allows
it to be a function instead of a delegate.
Re: Simple BeamUI project won't link
On Friday, 18 December 2020 at 19:15:16 UTC, Daren Scot Wilson wrote: On Wednesday, 16 December 2020 at 07:45:50 UTC, Ferhat Kurtulmuş wrote: On Wednesday, 16 December 2020 at 07:40:45 UTC, Ferhat Kurtulmuş wrote: This may be not your issue, but I could manage it to work by adding this line: subPackage "examples/myproject" to the dub.sdl of the beamui. I simply put my project in examples/ folder. And compile and run using: dub run :myproject The thought crossed my mind to try putting my source under examples/ but that's not a good way to organize a real project. I'd like it be under ~/projects/, naturally. What I want to make will involve a lot more than just a GUI. İf you don't need a fancy look and can live with simple widgets, Adam D. Ruppe's arsd repository has minigui. On windows it uses native Win32 API, so it doesn't need any dependency. https://github.com/adamdruppe/arsd
Re: Simple BeamUI project won't link
On Wednesday, 16 December 2020 at 07:45:50 UTC, Ferhat Kurtulmuş wrote: On Wednesday, 16 December 2020 at 07:40:45 UTC, Ferhat Kurtulmuş wrote: This may be not your issue, but I could manage it to work by adding this line: subPackage "examples/myproject" to the dub.sdl of the beamui. I simply put my project in examples/ folder. And compile and run using: dub run :myproject The thought crossed my mind to try putting my source under examples/ but that's not a good way to organize a real project. I'd like it be under ~/projects/, naturally. What I want to make will involve a lot more than just a GUI.
Re: Simple BeamUI project won't link
On Wednesday, 16 December 2020 at 07:40:45 UTC, Ferhat Kurtulmuş wrote: On Wednesday, 16 December 2020 at 07:02:11 UTC, Daren Scot Wilson wrote: Trying out the beamui GUI package, obtained by git clone from github. The "basic" example builds and runs. I'm working on an Arch Linux machine with lots of RAM, but a user with not enough practice at D yet. I have a little experience with beamui but only on windows. It is under WIP. You'd better open an issue with an error report on GitHub as I did before https://github.com/dayllenger/beamui/issues/16. You may get some help from the maintainer. So maybe beamui isn't ready for the real world. It's a one-off personal tool for image processing, maybe will go up on Github, so I don't need anything super-solid or well established. OTOH, if it's too much on the WIP side with lots of loose ends, it might be more work than my free time allows. At least, beamui appears to be more workable than dlangui which seems to have fallen away.
Re: Floating point values in structs.
On Friday, 18 December 2020 at 16:23:20 UTC, Adam D. Ruppe wrote: On Friday, 18 December 2020 at 16:18:12 UTC, Dave P. wrote: Is the proper solution to change the struct definition to: yeah that's the best option right now A bit of a pain when porting, but alright. I find the setting floats to nan pretty bizarre. yeah i wrote about it here not long ago http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_23.html#looking-back [...] I agree. Thanks!
Re: UFCS functions with both pointers and refs
Two differents types; Foo type and pointer type. Need function overload foe each or just use ref and avoid pointer.
Re: LDC relocation flags
On Friday, 18 December 2020 at 13:00:45 UTC, Severin Teona wrote: Hi guys! Do you know how can I compile D code using LDC with the following gcc flags? * -msingle-pic-base * -mpic-register=r9 * -mno-pic-data-is-text-relative. As far as I know, there are no equivalents in D for these. Is is ok to use the -Xcc flag? Thank you! One direction to look into is what flags to use with Clang instead of GCC. The -Xcc flag is not useful because that will only help with linker configuration. At least the first two flags that you mention are related to parts of codegen that I think are not done by the linker. -Johan
Re: Floating point values in structs.
On Friday, 18 December 2020 at 16:18:12 UTC, Dave P. wrote: Is the proper solution to change the struct definition to: yeah that's the best option right now I find the setting floats to nan pretty bizarre. yeah i wrote about it here not long ago http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_23.html#looking-back excerpt: "See, the idea behind D's initialization is it catches uninitialized values at runtime. Null pointers crash. NaN floats give NaN results. \ff chars give invalid strings. The problem is it sets the initializer for int (and friends) to be 0. Which is actually pretty useful and convenient, so people rely on it. Now making uninitialized things an error is infeasible and the fact is it sets a habit to expect 0." so i think it should be changed. but floats and chars are all weird initialized so be aware of it
Floating point values in structs.
I got burned by behavior of struct initialization I didn’t
anticipate last night.
Consider a struct:
struct Foo {
float x, y, z;
int a, b, c;
}
My source C code was initializing it by doing something like:
Foo f = {.y = 3}
Which uses the C behavior that all the other fields will be set
to 0.
I thought that the D translation would be:
Foo f = {y: 3}
But to my surprise, that leaves x and z “default initialized”,
which means nan!
I have some large structs that are essentially configuration
settings for certain subsystems. Is the proper solution to change
the struct definition to:
struct Foo {
float x=0, y=0, z=0;
int a, b, c;
}
to get the behavior I want?
I find the setting floats to nan pretty bizarre. If the compiler
is going to introduce the overhead of initializing all the
variables anyway, why set it to nan when integer types get set to
the useful default of 0? And if it knows that I am not
initializing my floats, why not tell me?
LDC relocation flags
Hi guys! Do you know how can I compile D code using LDC with the following gcc flags? * -msingle-pic-base * -mpic-register=r9 * -mno-pic-data-is-text-relative. As far as I know, there are no equivalents in D for these. Is is ok to use the -Xcc flag? Thank you!
Re: Avoid deallocate empty arrays?
On 12/17/20 5:57 PM, H. S. Teoh wrote: On a side note, though, I find this idiosyncratic behaviour annoying when all I really want is to use an array as, e.g., a backing for a stack. For those cases, I ignore array capacity and keep a slice over the entire allocated storage, including elements that have been erased, and keep a separate index that represents the logical end-of-array. While .assumeSafeAppend does work well, it does represent a druntime function call, which introduces a slight runtime overhead, and it does come with a slight performace hit. Yeah, for quick-and-dirty stuff, runtime appending is decent. But I would much rather use an array + "valid" length for everything else, including stacks or buffers. assumeSafeAppend is not only a druntime call, but an opaque one. Which means it will never be inlined or optimized out. -Steve
Re: Avoid deallocate empty arrays?
On 12/17/20 1:10 PM, IGotD- wrote:
On Thursday, 17 December 2020 at 17:46:59 UTC, Steven Schveighoffer wrote:
This isn’t correct. Can you post the code that led you to believe this?
-Steve
Sure.
import std.algorithm;
import std.typecons;
import std.stdio;
struct Buffer
{
this(size_t size)
{
m_buffer.reserve = size;
}
void add(const void[] arr)
{
m_buffer ~= cast(ubyte[])arr;
}
string getSome()
{
if(m_buffer.length > 0)
{
return cast(string)m_buffer[0..$];
}
else
{
return "";
}
}
void remove(size_t size)
{
m_buffer = m_buffer.remove(tuple(0, size));
Here is where your issue is. It looks like you are removing the first
size elements of the array. Which moves all the rest to the front.
However, the array runtime still thinks you have the original number of
elements in the buffer.
You need to add:
m_buffer.assumeSafeAppend;
This tells the runtime "I'm done with all the elements that are beyond
this length."
And then it will work as you expect, no reallocation.
}
ubyte[] m_buffer;
}
void main()
{
Buffer b = Buffer(16);
b.add("aa");
writeln("b.m_buffer.length ", b.m_buffer.length, ",
b.m_buffer.capacity ", b.m_buffer.capacity);
string s = b.getSome();
assert(s == "aa");
b.remove(s.length);
writeln("b.m_buffer.length ", b.m_buffer.length, ",
b.m_buffer.capacity ", b.m_buffer.capacity);
}
This will print
b.m_buffer.length 2, b.m_buffer.capacity 31
b.m_buffer.length 0, b.m_buffer.capacity 0
capacity 0, suggests that the array has been deallocated.
This means it has 0 capacity for appending according to the runtime, NOT
that the array was deallocated. This is true of non-GC allocated slices
and slices which don't END at the array end.
For example:
auto arr = [1, 2, 3];
auto arr2 = arr[0 .. 2]; // slice off the last element
assert(arr2.capacity == 0);
assert(arr.capacity != 0);
Does this mean the array is deallocated? No, it means that if you
append, there is no capacity to add to. A capacity of 0 means "will
reallocate if you append".
Why does this happen? Because we don't want to stomp on the existing
data that could still be referenced via another slice (in this case arr)
that still points to the original data.
You can read a bit about the array runtime here:
https://dlang.org/articles/d-array-article.html
-Steve
Anyone has links to useful short-snippets of trait pattern examples?
The manual often doesn't show the full potential of traits on the
first sight or what they are really good for. But there are also
all-day scenarios where I would just be happy for a quick lookup.
For example, to assign a value to a class property which may have
setter-overloads, I'm using a pattern like this:
void Foo(T, string property)(Variant data, T object) {
static if(!isSomeFunction!(__traits(getMember, T, property)))
{
__traits(getMember, object, property) =
data.get!(typeof(__traits(getMember, object, property)));
} else {
foreach(ov; __traits(getOverloads, T, property)) {
static if((Parameters!ov).length == 1) {
__traits(getMember, object, property) =
data.get!(Parameters!ov[0]);
}
}
}
}
Somebody already may have a better implementation and of course
it depends on your code - but it shows how to use it.
The part with the overloads is also important here because
without it the compiler would complain about "functions cannot
return function" or similiar errors and you would think
__traits(getMember) could not handle that.
