Re: Use of GUID constants
On Thursday, 10 March 2016 at 15:48:14 UTC, Mike Parker wrote: Personally I would just declare one immutable value in module scope and be done with it. It really just doesn't matter. Unless you're following some sort of style guide, personal preference rules the day. I don't know if Rainers has a special reason for what he did with the Visual D code or if it was personal preference. There is one good reason for doing it VisualD way. It defines and uses smart pointers ComPtr(ISomething) where you can just write auto x = ComPtr!ISomeInterface(someObject); and if someObject has a different COM type this constructor will QueryInterface() for the proper interface, and to do this it needs to know its IID, so a common way to get IID knowing just an interface type is really helpful.
Re: is module ( std.experimental.logger) thread-safe.
On Thursday, 10 March 2016 at 23:56:14 UTC, ZombineDev wrote: On Sunday, 6 March 2016 at 09:54:49 UTC, Dsby wrote: I want to use the filelogger to my application. is the sharedLog() global and thread-safe. Yes, `FileLogger` internally uses `lockingTextWriter`, so it should be safe to call from multiple threads. Furthermore, the `sharedLog` property uses atomic load and store instructions, so it should be OK to concurrently change the shared logger. Thanks. I was test and used in my mutil-threads application. It works fine.
Re: is module ( std.experimental.logger) thread-safe.
On Sunday, 6 March 2016 at 09:54:49 UTC, Dsby wrote: I want to use the filelogger to my application. is the sharedLog() global and thread-safe. Yes, `FileLogger` internally uses `lockingTextWriter`, so it should be safe to call from multiple threads. Furthermore, the `sharedLog` property uses atomic load and store instructions, so it should be OK to concurrently change the shared logger.
Re: How to import for mixin contents only.
On Thursday, 10 March 2016 at 22:07:23 UTC, Andrea Fontana wrote:
On Thursday, 10 March 2016 at 17:43:08 UTC, Taylor Hillegeist
wrote:
I suppose the linker optimized the functions away since they
are now in their own section. But it seems a hacky way to do
this.
AFAIK assert(0) and other falsey assert have a special meaning
for compiler.
So probably it's not so hacky but just a way to say that case
can't happen.
It is used also for:
auto myfunc(int i)
{
if (i == 0) return 10;
else if (i == 1) return 3;
assert(0);
}
And also with non final switch using
switch(var)
{
case ...
...
default: assert(0);
}
I'm good with the assert(0), I'm not so happy with the linker not
being able to create a binary without the -ffunction-sections
option.
I think there needs to be a ctimport keyword or something. I
should not have to deal with the imports only used during compile
time. it is not a good thing.
Re: Is it safe to use 'is' to compare types?
On Thursday, 10 March 2016 at 02:14:19 UTC, H. S. Teoh wrote: On Thu, Mar 10, 2016 at 01:33:41AM +, Yuxuan Shui via Digitalmars-d-learn wrote: [...] You can't rely on invoking the compiler to link these objects, because if you're using shared libraries, it will be the OS's dynamic linker that will get invoked to resolve the references, and different versions of shared libraries may have a different set of TypeInfo's, and the compiler may not be able to generate the required TypeInfo's. A better way is to use the OS linker's "weak symbol" feature, where a symbol is allowed to be defined multiple times (with identical content), and the linker (both dynamic and static) will choose the first definition that it finds. However weak symbol overriding is deprecated on Linux (see ld.so(8)). If we want to go all out to solve this problem, there are clearly solutions. But for now there doesn't seem to be enough benefit to justify the amount of work needed. T
Re: How to import for mixin contents only.
On Thursday, 10 March 2016 at 17:43:08 UTC, Taylor Hillegeist
wrote:
I suppose the linker optimized the functions away since they
are now in their own section. But it seems a hacky way to do
this.
AFAIK assert(0) and other falsey assert have a special meaning
for compiler.
So probably it's not so hacky but just a way to say that case
can't happen.
It is used also for:
auto myfunc(int i)
{
if (i == 0) return 10;
else if (i == 1) return 3;
assert(0);
}
And also with non final switch using
switch(var)
{
case ...
...
default: assert(0);
}
Re: D and devkitARM
On Thursday, 10 March 2016 at 14:36:26 UTC, Nicholas Wilson wrote: Hmm. I apologise that this post is not in any logical order. dmd can only compile for x86 so you will have to use ldc or gdc makefiles are generally not used in d. you should be able to use the dub project settings file (dub.json or dub.sdl) to do most of the standard linking, as for some of the deeper magic I'm not sure. versioning: i'm not sure that d has a 3ds target version but it has an arm one. includes should not be an issue. If you cannot find bindings for ctru see if dstep can do it for you. I don't know what .v.pica or .shlist files are but you can use string imports to reference the data looks like the same idea can be used for the shader rule. However you may need to use a prehook script to call whatever "picassso" does first. Thanks for the suggestions. I know I need to use gdc, specifically the one found at ftp://ftp.gdcproject.org/binaries/devkitARM/ (or build it myself if this doesn't work for whatever reason). I'm starting to think a bigger problem aside from the Makefiles is just getting any D to compile with that gdc version at all. I'm pretty sure I need some sort of bare metal runtime. Would this be something that could work, or should I look elsewhere? https://bitbucket.org/timosi/minlibd ...This probably really is above my knowledge level, but I suppose I'll never learn if I don't give it a shot. Like I said, if anyone has any sort of advice on how I should approach this, I'd be happy to hear it.
Re: Trying to build a Scheme interpreter in D
On Wednesday, 9 March 2016 at 20:30:44 UTC, Guillaume Piolat wrote: On Tuesday, 8 March 2016 at 18:11:24 UTC, John wrote: You can go with Algebraic. I used to do that in scheme-d. Then I switched to a tagged union by hand to avoid a compiler regression. Algebraic was OK. 2x speed difference between DMD and LDC is common. You can build with -g and use Instruments. Thank you for your advice.
Re: How to import for mixin contents only.
On Thursday, 10 March 2016 at 17:24:51 UTC, Taylor Hillegeist wrote: On Thursday, 10 March 2016 at 17:22:58 UTC, Taylor Hillegeist wrote: On Thursday, 10 March 2016 at 17:05:26 UTC, Taylor Hillegeist wrote: On Thursday, 10 March 2016 at 16:51:32 UTC, Andrea Fontana wrote: On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor Hillegeist wrote: [...] I wonder if compiler is smart enaugh to undestand that dependency is not needed at runtime in this case: http://dpaste.dzfl.pl/fd3bc2a839a3 well the latest gdc isnt smart enough. So interestingly this will work if i add -ffunction-sections to my compiler options? no idea why? However my binary goes from 4kb with static text to 11kb with the above change. I suppose the linker optimized the functions away since they are now in their own section. But it seems a hacky way to do this.
Re: How to import for mixin contents only.
On Thursday, 10 March 2016 at 17:22:58 UTC, Taylor Hillegeist wrote: On Thursday, 10 March 2016 at 17:05:26 UTC, Taylor Hillegeist wrote: On Thursday, 10 March 2016 at 16:51:32 UTC, Andrea Fontana wrote: On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor Hillegeist wrote: [...] I wonder if compiler is smart enaugh to undestand that dependency is not needed at runtime in this case: http://dpaste.dzfl.pl/fd3bc2a839a3 well the latest gdc isnt smart enough. So interestingly this will work if i add -ffunction-sections to my compiler options? no idea why? However my binary goes from 4kb with static text to 11kb with the above change.
Re: How to import for mixin contents only.
On Thursday, 10 March 2016 at 17:05:26 UTC, Taylor Hillegeist wrote: On Thursday, 10 March 2016 at 16:51:32 UTC, Andrea Fontana wrote: On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor Hillegeist wrote: [...] I wonder if compiler is smart enaugh to undestand that dependency is not needed at runtime in this case: http://dpaste.dzfl.pl/fd3bc2a839a3 well the latest gdc isnt smart enough. So interestingly this will work if i add -ffunction-sections to my compiler options? no idea why?
Re: How to import for mixin contents only.
On Thursday, 10 March 2016 at 16:51:32 UTC, Andrea Fontana wrote:
On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor Hillegeist
wrote:
I feel like this should do what i want it too. but it doesn't.
struct Color_t {
static if(1==1){
import std.bitmanip:bitfields;
immutable string item = bitfields!(
uint, "R",8,
uint, "G", 8,
uint, "B",8,
uint, "A", 8);
}
mixin(item);
}
I wonder if compiler is smart enaugh to undestand that
dependency is not needed at runtime in this case:
http://dpaste.dzfl.pl/fd3bc2a839a3
well the latest gdc isnt smart enough.
immutable(string) BF(){
if(!__ctfe)
assert(0);
import std.bitmanip:bitfields;
return bitfields!(
uint, "R", 8,
uint, "G", 8,
uint, "B", 8,
uint, "A", 8);
}
struct Color_t {
mixin(BF());
}
is a fair try as well. but neither work.
Re: How to import for mixin contents only.
On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor Hillegeist
wrote:
I feel like this should do what i want it too. but it doesn't.
struct Color_t {
static if(1==1){
import std.bitmanip:bitfields;
immutable string item = bitfields!(
uint, "R",8,
uint, "G", 8,
uint, "B",8,
uint, "A", 8);
}
mixin(item);
}
I wonder if compiler is smart enaugh to undestand that dependency
is not needed at runtime in this case:
http://dpaste.dzfl.pl/fd3bc2a839a3
Re: How to import for mixin contents only.
On Thursday, 10 March 2016 at 04:56:52 UTC, Mike Parker wrote:
On Thursday, 10 March 2016 at 04:07:54 UTC, Taylor Hillegeist
wrote:
So i want bitfields for just a little bit. but i dont want its
dependencies. How is it done. I have tried this. but it doesnt
seem to work on gdc. :(
struct Color_t {
static if(__ctfe){
import std.bitmanip:bitfields;
}
mixin(bitfields!(
uint, "R",8,
uint, "G", 8,
uint, "B",8,
uint, "A", 8));
}
__ctfe is a runtime construct, not compile-time. It cannot be
used with static if. More over, it's only available *inside* a
function that is currently being executed in a compile-time
context. It has no role outside of that.
What problem are you trying to solve here? I mean, what is the
problem with whatever dependencies std.bitmanip:bitfields has
that makes you only want to import it during compilation?
I feel like this should do what i want it too. but it doesn't.
struct Color_t {
static if(1==1){
import std.bitmanip:bitfields;
immutable string item = bitfields!(
uint, "R",8,
uint, "G", 8,
uint, "B",8,
uint, "A", 8);
}
mixin(item);
}
Re: Use of GUID constants
On Thursday, 10 March 2016 at 14:52:16 UTC, KlausO wrote:
For GUIDs you often have to take the address (e.g. for calls to
QueryInterface), so I think phobos does not correctly implement
this.
Yes, that was my meaning.
Is the above pair (const GUID and static member) the right way
to declare this idiom or would the following be better ?
Both compile and seem to be equivalent (in terms of achieving
the same goal):
enum IID IID_IServiceProvider = { 0x6d5140c1, 0x7436, 0x11ce, [
0x80, 0x34, 0x00, 0xaa, 0x00, 0x60, 0x09, 0xfa ] };
interface IServiceProvider : IUnknown
{
static immutable GUID iid = IID_IServiceProvider;
public:
/* [local] */ HRESULT QueryService(
/* [in] */ in GUID* guidService,
/* [in] */ in IID* riid,
/* [out] */ void **ppvObject);
}
Personally I would just declare one immutable value in module
scope and be done with it. It really just doesn't matter. Unless
you're following some sort of style guide, personal preference
rules the day. I don't know if Rainers has a special reason for
what he did with the Visual D code or if it was personal
preference.
As for Phobos, the Win32 API in Phobos as it stands now was a
recent addition. Though it existed as a third-party package for
several years, it may still have some kinks to work out and may
not follow the Phobos style guide in some places.
Re: Classes and CTFE
On Thursday, 10 March 2016 at 14:36:18 UTC, Adam D. Ruppe wrote: On Thursday, 10 March 2016 at 13:56:18 UTC, Andrea Fontana wrote: I used to think that classes can't be used with CTFE. Classes have worked normally with CTFE for several years now. You don't need to do anything special with them. Ex: http://dpaste.dzfl.pl/5879511dff02 This just doesn't do what you think it does: if (__ctfe) pragma(msg, "compile-time"); That will ALWAYS print the thing because if(__ctfe) is a *run time* branch, and pragma(msg) is a compile time thing. The code gets compiled, even if __ctfe == false, so it will print anyway. Yes but in one case it will print only that message, if instanced at runtime it will print the other too. I was just verifing if ctor was called correctly (in a more complex code) enum forceCTFE(alias expr)=expr; That's only one way to do CTFE. I just wanted to be sure it is ctfe. Notice the error message: variable p.forceCTFE!(willnot).forceCTFE : Unable to initialize enum with class or pointer to struct. Use static const variable instead. enums don't work in references, so you do a static variable instead. Static variables are still CTFE'd. So problem is actually enum, not ctfe. Nice. Thank you :)
Re: Use of GUID constants
For GUIDs you often have to take the address (e.g. for calls to
QueryInterface), so I think phobos does not correctly implement this.
In the meantime I took a look at the VisualD project which accesses the
COM interfaces of visual studio. They solve the problem by using the
following idiom (see
https://github.com/D-Programming-Language/visuald/blob/master/sdk/port/servprov.d
for an example):
const GUID IID_IServiceProvider = IServiceProvider.iid;
interface IServiceProvider : IUnknown
{
static const GUID iid = { 0x6d5140c1, 0x7436, 0x11ce, [ 0x80, 0x34,
0x00, 0xaa, 0x00, 0x60, 0x09, 0xfa ] };
public:
/* [local] */ HRESULT QueryService(
/* [in] */ in GUID* guidService,
/* [in] */ in IID* riid,
/* [out] */ void **ppvObject);
}
If every interface declaration contains the static iid member this
enables you to provide something similar to the the __uuidof operator in
VisualC (see https://msdn.microsoft.com/de-de/library/zaah6a61.aspx).
In VisualD something along that line is implemented in the qi_cast
template (see
https://github.com/D-Programming-Language/visuald/blob/master/stdext/com.d).
Is the above pair (const GUID and static member) the right way to
declare this idiom or would the following be better ?
Both compile and seem to be equivalent (in terms of achieving the same
goal):
enum IID IID_IServiceProvider = { 0x6d5140c1, 0x7436, 0x11ce, [ 0x80,
0x34, 0x00, 0xaa, 0x00, 0x60, 0x09, 0xfa ] };
interface IServiceProvider : IUnknown
{
static immutable GUID iid = IID_IServiceProvider;
public:
/* [local] */ HRESULT QueryService(
/* [in] */ in GUID* guidService,
/* [in] */ in IID* riid,
/* [out] */ void **ppvObject);
}
Thanks for your insights
-- KlausO
Am 10.03.2016 um 14:49 schrieb Mike Parker:
On Thursday, 10 March 2016 at 10:16:30 UTC, KlausO wrote:
Ok, but what's the intention behind defining GUIDs as enums in the
first place ?
Probably just an implementation error, i.e. someone not fully
appreciating how GUIDs are intended to be used.
Is there a recommended way to declare/define constants (e.g. as enums
or consts) ?
Generally, you should use a manifest constant, e.g.
enum myConst = 10;
Unless you need to take the address, then you should use immutable:
immutable myConst = 10;
The value of a manifest constant is substituted for the symbol at the
point of use and is not stored in the data segment (so has no memory
address), but an immutable (or const) variable is stored in the data
segment.
Re: Classes and CTFE
On Thursday, 10 March 2016 at 13:56:18 UTC, Andrea Fontana wrote: I used to think that classes can't be used with CTFE. Classes have worked normally with CTFE for several years now. You don't need to do anything special with them. Ex: http://dpaste.dzfl.pl/5879511dff02 This just doesn't do what you think it does: if (__ctfe) pragma(msg, "compile-time"); That will ALWAYS print the thing because if(__ctfe) is a *run time* branch, and pragma(msg) is a compile time thing. The code gets compiled, even if __ctfe == false, so it will print anyway. enum forceCTFE(alias expr)=expr; That's only one way to do CTFE. Notice the error message: variable p.forceCTFE!(willnot).forceCTFE : Unable to initialize enum with class or pointer to struct. Use static const variable instead. enums don't work in references, so you do a static variable instead. Static variables are still CTFE'd.
Re: D and devkitARM
On Wednesday, 9 March 2016 at 00:34:44 UTC, TheGag96 wrote: Hi guys, for a possibly-in-over-my-head project I'd like to get working a simple "Hello World" type program in which I call a D function from C in a 3DS homebrew app (or maybe even have it all in plain D with bindings to libctru). The thing is, I'm not skilled with Makefiles so I don't have a clue on how to correctly set up the toolchain for linking everything. I can compile some D-calling C code just fine with dmd and gcc on Linux (though I can't get anything working with gdc for whatever reason). Would anyone be able to point me in the right direction? This is the example Makefile for a 3DS homebrew app: http://pastebin.com/fcJrrMg9 It seems like there would be issues differentiating the .d build definition files from D source files... Thanks! Hmm. I apologise that this post is not in any logical order. dmd can only compile for x86 so you will have to use ldc or gdc makefiles are generally not used in d. you should be able to use the dub project settings file (dub.json or dub.sdl) to do most of the standard linking, as for some of the deeper magic I'm not sure. versioning: i'm not sure that d has a 3ds target version but it has an arm one. includes should not be an issue. If you cannot find bindings for ctru see if dstep can do it for you. I don't know what .v.pica or .shlist files are but you can use string imports to reference the data looks like the same idea can be used for the shader rule. However you may need to use a prehook script to call whatever "picassso" does first.
Classes and CTFE
I used to think that classes can't be used with CTFE. Instead it appears to work, if they're not directly returned but, for example, they're wrapped inside a struct as on example [1]. Ctor is called *only* at compile time, and instance works fine. So, I can't understand: why wrapping a class inside a struct make it works? Ex: http://dpaste.dzfl.pl/5879511dff02
Re: Use of GUID constants
On Thursday, 10 March 2016 at 10:16:30 UTC, KlausO wrote: Ok, but what's the intention behind defining GUIDs as enums in the first place ? Probably just an implementation error, i.e. someone not fully appreciating how GUIDs are intended to be used. Is there a recommended way to declare/define constants (e.g. as enums or consts) ? Generally, you should use a manifest constant, e.g. enum myConst = 10; Unless you need to take the address, then you should use immutable: immutable myConst = 10; The value of a manifest constant is substituted for the symbol at the point of use and is not stored in the data segment (so has no memory address), but an immutable (or const) variable is stored in the data segment.
Re: Memory Efficient HashSet
On 3/8/16 3:12 AM, Nordlöw wrote: Has anybody put together a memory-efficient D-implementation of a HashSet Something like sparse_hash_set<> contained in https://github.com/sparsehash/sparsehash but in D. D needs a way to use allocators for hash nodes. In Dcollections, both the performance and memory usage I was able to optimize by using a specialized allocator that allocates in pages and then divides up the pages. -Steve
Re: GC scan for pointers
On Wednesday, 9 March 2016 at 15:14:02 UTC, Gerald Jansen wrote:
I've studied [1] and [2] but don't understand everything there.
Hence these dumb questions:
Given
enum n = 100_000_000; // some big number
auto a = new ulong[](n);
auto b = new char[8][](n);
struct S { ulong x; char[8] y; }
auto c = new S[](n);
will the large memory blocks allocated for a, b and/or c
actually be scanned for pointers to GC-allocated memory during
a garbage collection? If so, why?
I've just tested it with my GC tracker (
https://bitbucket.org/infognition/dstuff ), all 3 allocations go
with flags APPENDABLE | NO_SCAN which means these blocks will not
be scanned.
But if you define S as
struct S { ulong x; char[] y; }
so there is some pointer inside, then it gets allocated with just
APPENDABLE flag, i.e. it will be scanned then.
Re: Memory Efficient HashSet
On Wednesday, 9 March 2016 at 22:31:50 UTC, Nordlöw wrote:
consumes 842.m MiB on my Ubuntu.
Here's mine:
https://bitbucket.org/infognition/robinhood/src
(you just need one file rbhash.d to use in your apps)
The following test takes ~130 MB and can take less with some
tweaks in the settings:
import std.stdio, rbhash;
alias Set(T) = RHHash!(T, void);
void main() {
auto set = new Set!uint;
foreach(i; 0..10_000_000)
set.add(i);
writeln(set.contains(444));
readln;
}
It's a GC-free Robin Hood hash table implementation with special
treatment for void as value type, i.e. sets.
Re: Memory Efficient HashSet
On Thursday, 10 March 2016 at 10:15:10 UTC, Martin Tschierschke wrote: With how many data sets at the end, you will have to deal? I need something close to the memory overhead of a sorted array of values. That is why I'm considering converting SparseHash's sparse_hash_set to D.
Re: Memory Efficient HashSet
On Wednesday, 9 March 2016 at 22:31:50 UTC, Nordlöw wrote: My knowledge database engine I'm building cannot afford the memory overhead of D's builtin associative arrays. Sounds like a cool project! You could also look into using a trie.
Re: Use of GUID constants
Ok, but what's the intention behind defining GUIDs as enums in the first place ? Why not defining them as const(GUID) and let the linker sort them out ? Is there a recommended way to declare/define constants (e.g. as enums or consts) ? In C (separate compilation) they are declared as "EXTERN_C const GUID" and you use one C file to define this GUIDs for the Linker. Thanks -- KlausO For the record, found two somehow related issues in bugzilla: https://issues.dlang.org/show_bug.cgi?id=14309 https://issues.dlang.org/show_bug.cgi?id=4092 Am 09.03.2016 um 23:20 schrieb Ali Çehreli: On 03/09/2016 10:35 AM, KlausO wrote: > IUnknown pUnk; > > // > // Does not compile: > // > // Error: function > core.sys.windows.unknwn.IUnknown.QueryInterface(const(GUID)* riid, > void** pvObject) is not callable using argument types (const(GUID), void**) > // > hr = storage.QueryInterface(IID_IUnknown, cast(void**)&pUnk); Without any experience with COM or (current) Windows programming, just by looking at that error message, the following may work: IID unknown = IID_IUnknown; // (Apparently, IID is an alias for const(GUID).) storage.QueryInterface(&unknown, /* ... */); Ali
Re: Memory Efficient HashSet
On Wednesday, 9 March 2016 at 22:31:50 UTC, Nordlöw wrote: The consumption with Google's sparsehash unordered_set is about 50 MiB. See also: http://smerity.com/articles/2015/google_sparsehash.html
Re: Memory Efficient HashSet
On Wednesday, 9 March 2016 at 22:31:50 UTC, Nordlöw wrote:
[...]
foreach (const i; iota(0, n))
{
x[i] = true; // indicate that it's stored
}
import std.stdio : writeln, readln;
writeln("Press return: ");
readln;
}
consumes 842.m MiB on my Ubuntu.
The consumption with Google's sparsehash unordered_set is about
50 MiB.
May be the discussion associated with this post, can give help???
https://forum.dlang.org/post/mailman.217.1457590242.26339.digitalmars-d-b...@puremagic.com
I tried your little program and played around. I tried x.rehash,
but this resulted in even more memory consumption. 80 bytes for 4
bytes key and one bit storage seams a lot.
With smaller n it comes down to app. 60 Bytes.
With how many data sets at the end, you will have to deal?
Re: Cannot compile program with DMD built from source
On Wednesday, 9 March 2016 at 16:13:38 UTC, Minas Mina wrote: Hello, I have followed the instructions here (http://wiki.dlang.org/Starting_as_a_Contributor#POSIX) to install DMD, druntime and phobos from source. My platform is Ubuntu 15.10 x64. This is the error I get: http://pastebin.com/kWCv0ymn It seems it tries to link against a wrong Phobos version. Try running dmd with the `-v`, it will output how it invokes the linker (usually starting with "cc"). Maybe you have to adjust your dmd.conf, or create one. I like to place a link to dmd in my ~/bin directory (which is in $PATH), and put a dmd.conf next to it, so it's picked up automatically: [Environment] DFLAGS=-I/home/marc/d/phobos -I/home/marc/d/druntime/import -L-L/home/marc/d/phobos/generated/linux/release/64/ -L--no-warn-search-mismatch -L--export-dynamic
