Re: x64 Privileged instruction
On Wednesday, 12 September 2018 at 13:26:03 UTC, Stefan Koch wrote: On Wednesday, 12 September 2018 at 10:42:08 UTC, Josphe Brigmo wrote: x64 gives Privileged instruction but x86 gives First-chance exception: std.file.FileException "C:\": The filename, directory name, or volume label syntax is incorrect. at std\file.d(4573) which is much more informative... seems like a bug to me. More context needed. What code does produce this behavior. Lots of code. I pretty much always get this error. Just throw. It is a first chance exception so that should be clear enough. The point is that x64 doesn't seem to handle first chance exceptions and gives a privileged instruction. This happens windows 10 visual D and I've had it happen for a long time.
Re: Shared, ref, arrays, and reserve template instantiation
Great -- Thank you both. I previously found Unqual, but it looks like that needs template support so wasn't feasible, hence my question. Neia is right that I tried to cast as in the second case ( but without UFCS -- reserve( cast(int[]), N); ). As an aside, what is going on behind the scenes with the compiler when casting away a property? I did not think cast operations copied data, so was surprised that a cast value is not an lvalue. Regarding Jonathan's comments, we had definitely protected the ~= operations with Mutex, but realized we were doing lots of array appends in a hot loop, and since we have an idea of cardinality ahead of time just wanted to preallocate. Since it is all initialization before concurrent code enters the picture, we'll do what you've suggested and set it up as TL and then cast to shared. James
Re: Shared, ref, arrays, and reserve template instantiation
On Wednesday, September 12, 2018 5:41:16 PM MDT James Blachly via
Digitalmars-d-learn wrote:
> When I add the "shared" attribute to an array, I am no longer
> able to call reserve because the template won't instantiate:
>
> Error: template object.reserve cannot deduce function from
> argument types !()(shared(int[]), int), candidates are:
> /dlang/dmd/linux/bin64/../../src/druntime/import/object.d(4091):
>object.reserve(T)(ref T[] arr, size_t newcapacity)
>
> 1. Shared modifies the type, so the template does not match. Even
> casting does not seem to work however. Is there something about
> shared that makes it unable to be taken by reference?
> 2. Is there a workaround for me to be able to preallocate the
> array?
You can't do much of anything with shared while it's shared, which is pretty
much the whole point. The way that shared needs to be used in general is
essentially
synchronized(mutexForSharedObj)
{
auto local = cast(Type)sharedObj;
// do stuff with local...
// ensure that no thread-local references to local / sharedObj exist
// before releasing the mutex
}
// shared object is now essentially unusable again
Doing pretty much _any_ operation on a shared object while it's shared
(other than atomic operations from core.atomic) is wrong, because it's not
thread-safe. The compiler prevents most operations but not as many as it
should (e.g. copying is currently legal). That will likely be fixed in the
future, but exactly what's going to happen to shared in all of the fine
details hasn't been sorted out yet. The basics work, but not all of the
details are as they should be yet.
So, if you're doing anything like calling reserve or ~= on a shared array,
then you need to protect it with the mutex that you have for it and cast
away shared first. However, if you're just dealing with constructing the
array, then what you should do is create it as thread-local and then cast it
to shared after you're done setting it up and are ready to share it across
threads (after which, all further operations on it should be protected by a
mutex or use atomics, otherwise they're not thread-safe).
- Jonathan M Davis
Re: Shared, ref, arrays, and reserve template instantiation
On Wednesday, 12 September 2018 at 23:41:16 UTC, James Blachly wrote: When I add the "shared" attribute to an array, I am no longer able to call reserve because the template won't instantiate: Error: template object.reserve cannot deduce function from argument types !()(shared(int[]), int), candidates are: /dlang/dmd/linux/bin64/../../src/druntime/import/object.d(4091): object.reserve(T)(ref T[] arr, size_t newcapacity) 1. Shared modifies the type, so the template does not match. Even casting does not seem to work however. Is there something about shared that makes it unable to be taken by reference? 2. Is there a workaround for me to be able to preallocate the array? Kind regards I'm guessing you tried something like: shared char[] x; // Doesn't work; it casts the result of x.reserve cast(char[])x.reserve(100); // Doesn't work; (cast(char[])x) is not an lvalue, so it can't be ref (cast(char[])x).reserve(100); Arrays are passed and stored like pointers, and `reserve` modifies the array, which is why the thing needs to be ref. Anyway, it works like this: // Cast and store in a variable so it can be ref auto b = cast(char[]) x; // Okay, reallocates b (changes b.ptr), doesn't change x b.reserve(100); // Copy changes back to the shared variable x = cast(shared) b;
Shared, ref, arrays, and reserve template instantiation
When I add the "shared" attribute to an array, I am no longer able to call reserve because the template won't instantiate: Error: template object.reserve cannot deduce function from argument types !()(shared(int[]), int), candidates are: /dlang/dmd/linux/bin64/../../src/druntime/import/object.d(4091): object.reserve(T)(ref T[] arr, size_t newcapacity) 1. Shared modifies the type, so the template does not match. Even casting does not seem to work however. Is there something about shared that makes it unable to be taken by reference? 2. Is there a workaround for me to be able to preallocate the array? Kind regards
Re: Variadic template with template arguments in pairs
On Wednesday, 12 September 2018 at 15:12:16 UTC, Anonymouse wrote:
void doByPair(Args...)(Args args)
if (Args.length)
{
foreach (pair; args.pairwise)
{
static assert(is(typeof(pair[0]) == string));
static assert(isPointer!(pair[1]));
assert(pair[1] !is null);
string desc = pair[0];
auto value = *pair[1];
writefln("%s %s: %s", typeof(value).stringof, desc,
value);
}
}
The easiest way is probably to iterate using indices with an
increment of 2, e.g.:
static foreach(i; iota(0, args.length, 2))
{
static assert(is(typeof(args[i]) == string));
static assert(isPointer!(args[i+1]));
// etc.
}
Another alternative is to write the function recursively:
void doByPair(T, Rest...)(string desc, T* valuePtr, Rest rest)
{
writefln("%s %s: %s", T.stringof, desc, *valuePtr);
if (rest.length) doByPair(rest);
}
Re: DlangUI and android
On Monday, 10 September 2018 at 09:19:52 UTC, Josphe Brigmo wrote: Is there an emulator that can run the apks? Android emulator does not work, I suppose, because it isn't java. Complains about a missing classes.dex file. I'd rather have an emulator version if possible for quicker dev. For APKs I usually use Bluestacks [0]. Works great for Unity builds atleast. 0: https://www.bluestacks.com/
Re: Is it's correct to say that ALL types that can grow are place on heap?
On 13/09/2018 3:22 AM, Timoses wrote: On Wednesday, 12 September 2018 at 14:46:22 UTC, rikki cattermole wrote: On 13/09/2018 2:34 AM, drug wrote: 12.09.2018 15:14, Timoses пишет: On Tuesday, 11 September 2018 at 12:07:14 UTC, drug wrote: If data size is less or equal to total size of available registers (that can be used to pass values) than passing by value is more efficient. Passing data with size less than register size by reference isn't efficient because you pass pointer (that has register size) and access memory using it. Thank you! So if I pass by reference it will ALWAYS use the address in memory to fetch the data, whereas passing it by value enables the (compiler?..) to use the register which has already loaded the data from memory (stack for example)? Honestly, I'm not an expert in this domain, but I think so. Recently used areas of the stack will be available in the cache in most cases. The issue with passing by reference is it increases the indirection (number of pointers) that it must go through to get to the raw bytes. This is why classes are bad but structs are good. Even if the struct is allocated on the heap and you're accessing it via a pointer. This sounds like classes should never be used.. I don't recall right now what issues I'm usually encountering with structs that make me switch to classes (in D). Nah, this is cycle counting aka don't worry about it if you're not doing anything super high performance.
Re: Is it's correct to say that ALL types that can grow are place on heap?
On Wednesday, 12 September 2018 at 14:46:22 UTC, rikki cattermole wrote: On 13/09/2018 2:34 AM, drug wrote: 12.09.2018 15:14, Timoses пишет: On Tuesday, 11 September 2018 at 12:07:14 UTC, drug wrote: If data size is less or equal to total size of available registers (that can be used to pass values) than passing by value is more efficient. Passing data with size less than register size by reference isn't efficient because you pass pointer (that has register size) and access memory using it. Thank you! So if I pass by reference it will ALWAYS use the address in memory to fetch the data, whereas passing it by value enables the (compiler?..) to use the register which has already loaded the data from memory (stack for example)? Honestly, I'm not an expert in this domain, but I think so. Recently used areas of the stack will be available in the cache in most cases. The issue with passing by reference is it increases the indirection (number of pointers) that it must go through to get to the raw bytes. This is why classes are bad but structs are good. Even if the struct is allocated on the heap and you're accessing it via a pointer. This sounds like classes should never be used.. I don't recall right now what issues I'm usually encountering with structs that make me switch to classes (in D). So passing by reference is generally only applicable (logical) to structs and non-reference types + only makes sense when the function being called is supposed to change the referenced value without returning it. Except, as Steven pointed out in his post when dealing with large lvalue structs. This all seems quite complicated to "get right" when writing code. I'm sure there are compiler optimizations run on this? Or is that not possible due to the nature of difference in ref and value passing. Anyhow, thanks for the answers! I bet it's possible to write books on this topic.. Or just mention ones that already were written : ~D.
Re: DMD32 compiling gtkd out of memory on 32bit Windows 7 machine
On Wednesday, 12 September 2018 at 06:06:15 UTC, dangbinghoo wrote: hi , When compiling gtkd using dub, dmd32 reported "Out for memory" and exit. OS: Windows 7 32bit. RAM : 3GB DMD version: v2.0.82.0 32bit. No VC or Windows SDK installed, when setting up dmd, I selected install vc2010 and use mingw lib. try `dub --build-mode=singleFile` ? I believe this will compile each file and then link them together (instead of compiling it all together what dub does, afaik). There's been another topic on memory consumption of compilation [1]. [1]: https://forum.dlang.org/post/ehyfilopozdndjdah...@forum.dlang.org
Re: Pass 'this' as reference
On 9/12/18 8:01 AM, Jan wrote: I'm using D not for that long and lately I have encountered an issue. I have class 'Foo' with a constructor using this signature: `this (ref Bar original)` In the 'Bar' class itself I want to create an instance of 'Foo' using 'this' as parameter. Something in the way of: `Foo foo = new Foo(ref this);` I couldn't find anything interesting on the internet to help me. Could anyone help me? Many thanks in advance! You don't have to specify ref when calling. This should work: auto foo = new Foo(this); Though almost certainly you are misunderstanding classes -- they are references anyway. I don't know why you would want to accept a class via ref unless you were actually going to reassign the reference. I suggest that your constructor should not accept Bar via ref. -Steve
Variadic template with template arguments in pairs
I'm trying to create a variadic template function that takes
pairs of arguments. Sort of like getopt, I want to pass any
number of pairs of a string and some pointer. Or any size chunk
larger than one.
Something like the following, assuming the existence of a
hypothetical template pairwise:
---
void doByPair(Args...)(Args args)
if (Args.length)
{
foreach (pair; args.pairwise)
{
static assert(is(typeof(pair[0]) == string));
static assert(isPointer!(pair[1]));
assert(pair[1] !is null);
string desc = pair[0];
auto value = *pair[1];
writefln("%s %s: %s", typeof(value).stringof, desc,
value);
}
}
bool b1 = true;
bool b2 = false;
string s = "some string";
int i = 42;
doByPair("foo", , "bar", , "baz", , "qux", );
---
Should output:
bool foo: true
bool bar: false
string baz: some string
int qux: 42
What is the right way to go about doing this?
Re: Pass 'this' as reference
On Wednesday, 12 September 2018 at 15:01:36 UTC, Jan wrote: I'm using D not for that long and lately I have encountered an issue. I have class 'Foo' with a constructor using this signature: `this (ref Bar original)` classes and the ref keyword should very rarely be used together in D. classes are already refs without anything, so adding it makes it a double ref, which breaks more than it helps. If you just get rid of the `ref`s in your code it will probably work.
Pass 'this' as reference
I'm using D not for that long and lately I have encountered an issue. I have class 'Foo' with a constructor using this signature: `this (ref Bar original)` In the 'Bar' class itself I want to create an instance of 'Foo' using 'this' as parameter. Something in the way of: `Foo foo = new Foo(ref this);` I couldn't find anything interesting on the internet to help me. Could anyone help me? Many thanks in advance!
Re: Is it's correct to say that ALL types that can grow are place on heap?
On 13/09/2018 2:34 AM, drug wrote: 12.09.2018 15:14, Timoses пишет: On Tuesday, 11 September 2018 at 12:07:14 UTC, drug wrote: If data size is less or equal to total size of available registers (that can be used to pass values) than passing by value is more efficient. Passing data with size less than register size by reference isn't efficient because you pass pointer (that has register size) and access memory using it. Thank you! So if I pass by reference it will ALWAYS use the address in memory to fetch the data, whereas passing it by value enables the (compiler?..) to use the register which has already loaded the data from memory (stack for example)? Honestly, I'm not an expert in this domain, but I think so. Recently used areas of the stack will be available in the cache in most cases. The issue with passing by reference is it increases the indirection (number of pointers) that it must go through to get to the raw bytes. This is why classes are bad but structs are good. Even if the struct is allocated on the heap and you're accessing it via a pointer.
Re: Is it's correct to say that ALL types that can grow are place on heap?
12.09.2018 15:14, Timoses пишет: On Tuesday, 11 September 2018 at 12:07:14 UTC, drug wrote: If data size is less or equal to total size of available registers (that can be used to pass values) than passing by value is more efficient. Passing data with size less than register size by reference isn't efficient because you pass pointer (that has register size) and access memory using it. Thank you! So if I pass by reference it will ALWAYS use the address in memory to fetch the data, whereas passing it by value enables the (compiler?..) to use the register which has already loaded the data from memory (stack for example)? Honestly, I'm not an expert in this domain, but I think so.
Re: x64 Privileged instruction
On Wednesday, 12 September 2018 at 10:42:08 UTC, Josphe Brigmo wrote: x64 gives Privileged instruction but x86 gives First-chance exception: std.file.FileException "C:\": The filename, directory name, or volume label syntax is incorrect. at std\file.d(4573) which is much more informative... seems like a bug to me. More context needed. What code does produce this behavior.
Re: Is it's correct to say that ALL types that can grow are place on heap?
On 9/11/18 3:11 AM, Timoses wrote: Aww, I really would love some insights into function parameter passing. Why is it said that passing by value can be more efficient at times? Since it is also said that passing large structs by value can be expensive, why then would it not be cheaper to ALWAYS pass everything by reference? What mechanism is behind the scene that follows one to reason that sometimes passing by value is less expensive? So consider that accessing a struct from the function is cheaper when it is passed by value -- you have one offset from the stack pointer, and that's it. Vs. going through the stack pointer to get the reference, and then dereferencing that. In addition, passing a large struct by value can be as cheap or even cheaper if you can construct the value right where it is going to be passed. In other words, you don't need to make *any* copies. This can be true for rvalues that are passed by value, but not lvalues. So in addition to register passing, there are other benefits to consider. -Steve
Re: Is it's correct to say that ALL types that can grow are place on heap?
On Tuesday, 11 September 2018 at 12:07:14 UTC, drug wrote: If data size is less or equal to total size of available registers (that can be used to pass values) than passing by value is more efficient. Passing data with size less than register size by reference isn't efficient because you pass pointer (that has register size) and access memory using it. Thank you! So if I pass by reference it will ALWAYS use the address in memory to fetch the data, whereas passing it by value enables the (compiler?..) to use the register which has already loaded the data from memory (stack for example)?
x64 Privileged instruction
x64 gives Privileged instruction but x86 gives First-chance exception: std.file.FileException "C:\": The filename, directory name, or volume label syntax is incorrect. at std\file.d(4573) which is much more informative... seems like a bug to me.
DMD32 compiling gtkd out of memory on 32bit Windows 7 machine
hi , When compiling gtkd using dub, dmd32 reported "Out for memory" and exit. OS: Windows 7 32bit. RAM : 3GB DMD version: v2.0.82.0 32bit. No VC or Windows SDK installed, when setting up dmd, I selected install vc2010 and use mingw lib.
