Re: Get fils at compile-time
On 15/12/2016 8:11 PM, Bauss wrote: On Thursday, 15 December 2016 at 02:58:11 UTC, rikki cattermole wrote: I did a lot of work in this area. There are two solutions: 1) Use a package file and public import all modules via it. From this do some form of 'registration' in a module constructor. Using __traits(allMembers, retrieve the imports and with that the other modules. 2) Before compilation create a file that contains a list of all the module names. I prefer 2 now days. It's not D modules. I'm talking about loading dynamic file content from dynamically created files. The first one won't work, because it only imports modules and you still have to give DMD each module that you compile. The second one won't work either, because again the files are not D modules. They're regular files that I need to handle at compile-time. Besides your suggestion still requires manual work, which is what I need to avoid. I know how I can do it by specifying the files, but that's exactly what I want to avoid. I don't want to specify which files I need to handle, I just need to be able to handle all files in a folder without having to specify them somewhere after the creation. The second will still work, that file that contains a list of modules names can just as easily be a list of files to string import. Or is the files themselves it is after all generated by an external program before compilation. An example of this would be bin2d (looks like I never bothered to register it on code.dlang.org)[0]. [0] https://github.com/rikkimax/Bin2D
Re: Get fils at compile-time
On Thursday, 15 December 2016 at 02:58:11 UTC, rikki cattermole wrote: I did a lot of work in this area. There are two solutions: 1) Use a package file and public import all modules via it. From this do some form of 'registration' in a module constructor. Using __traits(allMembers, retrieve the imports and with that the other modules. 2) Before compilation create a file that contains a list of all the module names. I prefer 2 now days. It's not D modules. I'm talking about loading dynamic file content from dynamically created files. The first one won't work, because it only imports modules and you still have to give DMD each module that you compile. The second one won't work either, because again the files are not D modules. They're regular files that I need to handle at compile-time. Besides your suggestion still requires manual work, which is what I need to avoid. I know how I can do it by specifying the files, but that's exactly what I want to avoid. I don't want to specify which files I need to handle, I just need to be able to handle all files in a folder without having to specify them somewhere after the creation.
Re: Simplest way to build a DMD compatible C lib, and how to link using DUB.
On Wednesday, 14 December 2016 at 23:08:30 UTC, hardreset wrote: I built Freetype with MSVC13 and tried to link it but DMD didnt like the format, so what should compiler (free) should I use for building DMD compatible static libs? The MS linker produces COFF format. By default, DMD uses the OPTLINK linker, which only understands OMF. Assuming DMD is configured to find your MSVC installation, you can link directly with COFF libraries and objects by passing -m64 or -m32mscoff on the DMD command line. With DUB, use -ax86_64 on the command line to make it use -m64. Unfortunately, there is currently no such option for it to use -m32mscoff, so you need to configure it in your dub configuration with a "dflags" directive and make sure any dependencies are compiled that way as well. Once I've build the lib, made a di file, where do I put these things in the dub directory structure? Where ever you want. If you put the di file in your source directory, DUB will pick it up automatically. For libraries, I usually put them in a 'lib' subdirectory and add this in the module with my main method: version(Windows) pragma(lib, `lib\foo.lib`); As Basile recommended, DerelictFT[1] will save you from the hassle of object formats. It's a dynamic binding, so you don't need to link with FreeType at all during compilation. You simply call DerelictFT.load during initialization and it will load the FreeType DLL for you. However, if your goal is to use DLLs, then you either have to use the MS linker as I described above or get FreeType into the OMF format (either by compiling with DMC or using an object converter). [1] https://github.com/DerelictOrg/DerelictFT
Re: Get fils at compile-time
I did a lot of work in this area. There are two solutions: 1) Use a package file and public import all modules via it. From this do some form of 'registration' in a module constructor. Using __traits(allMembers, retrieve the imports and with that the other modules. 2) Before compilation create a file that contains a list of all the module names. I prefer 2 now days.
Re: DRY version of `static if(__traits(compiles, expr)) fun(expr)`
On Wednesday, 14 December 2016 at 22:06:35 UTC, Ali Çehreli wrote: On 12/14/2016 09:25 AM, Basile B. wrote: > On Tuesday, 13 December 2016 at 23:37:59 UTC, Timon Gehr wrote: >> I usually do >> >> enum code = q{expr}; >> static if(__traits(compiles,mixin(code))) >> fun(mixin(code)); > > Strangely if i put this in a templated enum that doesn't work. > If instead i use a delegate literal it works. > > enum Compiles(string code) = is(typeof((){mixin(code);})); > > enum Compiles2(string code) = __traits(compiles, mixin(code)); When you do that, the code does not match the syntax of __traits(compiles). Putting the code inside a scope works at least in this case: enum Compiles2(string code) = __traits(compiles, mixin('{' ~ code ~ '}')); Ali I see, it makes sense. Anyway the two templates have a common problem (protection attributes: data used in the code must be visible to the outside), so using them as a shortcut is a false good idea.
Re: Dynamically Loading a D DLL From a D Program
On Wednesday, 14 December 2016 at 21:38:27 UTC, Benjiro wrote: Silly question: In this post about static / dynamic loading, i noticed that it uses the dlopen/dlclose, while there is a core.runtime for handling the loading. http://dlang.org/dll-linux.html#dso9 Dynamically Loading a D DLL From a D Program [...] Is it not better to use: [...] Is there also any information regarding d classes loading instead of functions? It also seems that the core runtime is incomplete with basic loading but no handling of dlsym, so your still forced to use the basic c conversion casting. [...] There is also derelict shared lib loader in derelict-util in dub.
Re: Simplest way to build a DMD compatible C lib, and how to link using DUB.
On Wednesday, 14 December 2016 at 23:08:30 UTC, hardreset wrote: I built Freetype with MSVC13 and tried to link it but DMD didnt like the format, so what should compiler (free) should I use for building DMD compatible static libs? Once I've build the lib, made a di file, where do I put these things in the dub directory structure? thanks, Yes under win32 you must use Digital Mars C++ compiler, "DMC", because it produces OMF objects. That's also the default format produced by DMD. DMC is here: http://www.digitalmars.com/download/freecompiler.html However note that there's DerelictFT or Deimos freetype if you don't want to mess with this problem.
Simplest way to build a DMD compatible C lib, and how to link using DUB.
I built Freetype with MSVC13 and tried to link it but DMD didnt like the format, so what should compiler (free) should I use for building DMD compatible static libs? Once I've build the lib, made a di file, where do I put these things in the dub directory structure? thanks,
Re: DRY version of `static if(__traits(compiles, expr)) fun(expr)`
On 12/14/2016 09:25 AM, Basile B. wrote: > On Tuesday, 13 December 2016 at 23:37:59 UTC, Timon Gehr wrote: >> I usually do >> >> enum code = q{expr}; >> static if(__traits(compiles,mixin(code))) >> fun(mixin(code)); > > Strangely if i put this in a templated enum that doesn't work. > If instead i use a delegate literal it works. > > enum Compiles(string code) = is(typeof((){mixin(code);})); > > enum Compiles2(string code) = __traits(compiles, mixin(code)); When you do that, the code does not match the syntax of __traits(compiles). Putting the code inside a scope works at least in this case: enum Compiles2(string code) = __traits(compiles, mixin('{' ~ code ~ '}')); Ali
Dynamically Loading a D DLL From a D Program
Silly question: In this post about static / dynamic loading, i noticed that it uses the dlopen/dlclose, while there is a core.runtime for handling the loading. http://dlang.org/dll-linux.html#dso9 Dynamically Loading a D DLL From a D Program void* lh = dlopen("libdll.so", RTLD_LAZY); // Do Stuff dlclose(lh); Is it not better to use: import core.runtime : Runtime; void* lib = Runtime.loadLibrary(fileName); // Do Stuff Runtime.unloadLibrary(lib); Is there also any information regarding d classes loading instead of functions? It also seems that the core runtime is incomplete with basic loading but no handling of dlsym, so your still forced to use the basic c conversion casting. int function() fn = cast(int function())dlsym(lib, libFunction); fn();
Re: Get fils at compile-time
On Wednesday, 14 December 2016 at 20:47:23 UTC, bauss (wtf happend to my name took some old cached title LOL??) wrote: Is there a way to get all files in a folder at compile-time. To be more specific I want to import the content of all files within a specific folder during compile-time. I know how to do it with a specific file using `import("filename")`, but what if I wanted to do it at compile-time for all files in a folder then loop through those files and handle their content. [...] Also excuse me for the title. It's supposed to be "files"
Get fils at compile-time
2016-12-14
Thread
bauss (wtf happend to my name took some old cached title LOL??) via Digitalmars-d-learn
Is there a way to get all files in a folder at compile-time. To be more specific I want to import the content of all files within a specific folder during compile-time. I know how to do it with a specific file using `import("filename")`, but what if I wanted to do it at compile-time for all files in a folder then loop through those files and handle their content. To give an example. Let's say I have a folder "styles" it has 3 files "global.stylesheet", "main.stylesheet", "shared.stylesheet". Now I don't know about these file's names, so I can't just do it manually as they could be "foo", "bar" and "baz", just like they're "global", "main" and "shared". There could even be more files, so eventually I'd have to load all files in somehow. Ex. enum string[] compileTimeFiles = loadFilesSomehowHere("styles"); Now if it was possible to just get the file names into `compileTimeFiles` then I could use "import" on each file name, but how would I even get them into that, if it's even possible? Tbh. it's a very reasonable use-case if you ask me. Especially if it comes to dynamic generation of either code related to UI applications, web applications, websites etc.
Re: DRY version of `static if(__traits(compiles, expr)) fun(expr)`
On Tuesday, 13 December 2016 at 23:37:59 UTC, Timon Gehr wrote: On 14.12.2016 00:00, Timothee Cour via Digitalmars-d-learn wrote: what's the best (and DRY) way to achieve: ``` static if(__traits(compiles, expr)) fun(expr); ``` ie, without repeating the expression inside expr? eg: ``` static if(__traits(compiles, foo.bar[2])){ counter++; writeln(" expr = ", foo.bar[2]); } ``` I usually do enum code = q{expr}; static if(__traits(compiles,mixin(code))) fun(mixin(code)); Strangely if i put this in a templated enum that doesn't work. If instead i use a delegate literal it works. enum Compiles(string code) = is(typeof((){mixin(code);})); enum Compiles2(string code) = __traits(compiles, mixin(code)); unittest { static assert(Compiles!q{auto a = 1+1;}); static assert(!Compiles!q{1;}); static assert(!Compiles!q{a = 1;}); static assert(Compiles2!q{auto a = 1+1;}); static assert(!Compiles2!q{1;}); static assert(!Compiles2!q{a = 1;}); } wtf ?
Re: Issue with dmd, linker, visualD on windows 10
On Wednesday, 14 December 2016 at 12:06:01 UTC, rumbu wrote: On Wednesday, 14 December 2016 at 11:06:10 UTC, aberba wrote: [...] If he runs the command in an already open console window, that's normal. A new console window launch will be enough to know about the recent environment path change. [...] Visual Studio doesn't work directly with source files, but with project files. This is not D-specific. I'm sure that if you edit a simple .c file in Visual Studio, it will never launch the C compiler. Create a new project (Console Application) and it will work. [...] I think this is also a environment variables problem, the linker needs some libs and does not know how to find them. Ask Cortana for "D2 32-bit Command Prompt", this batch file will open a new command prompt with all the environment variables properly set. Thanks. The coolest part is cortona. :)
Re: Issue with dmd, linker, visualD on windows 10
On Wednesday, 14 December 2016 at 11:06:10 UTC, aberba wrote: I am trying to get a fellow to try D but just setting up on windows 10 has been headache. He's currently remote. Here's the problem. (Note I'm a Linux user and haven't used windows 10) 1. He installed dmd 2 but the command "dmd" is not recognized. He confirmed and c:\D\dmd2\windows\bin is in system path. Why? If he runs the command in an already open console window, that's normal. A new console window launch will be enough to know about the recent environment path change. 2. He installed visual studio 2015 and visualD(pointed it to dmd location during installation), restarted visual studio. Without creating a visualD project, "compile and run" does nothing when he clicks. We haven't tried creating a project though, just using a D file with simple "Hello, world!" code. Syntax highlighting work though. Visual Studio doesn't work directly with source files, but with project files. This is not D-specific. I'm sure that if you edit a simple .c file in Visual Studio, it will never launch the C compiler. Create a new project (Console Application) and it will work. 3. He navigated to ...dmd2\windows\bin where "dmd" command works. But "dmd -run file.d" says Oplink error, linker exited with code ... I think this is also a environment variables problem, the linker needs some libs and does not know how to find them. Ask Cortana for "D2 32-bit Command Prompt", this batch file will open a new command prompt with all the environment variables properly set.
Re: Alias variable from another class
On Tuesday, 13 December 2016 at 19:13:24 UTC, Begah wrote: Any ideas? you can't.
Re: Accessing members through pointers to structs (also, CTFE associative arrays)
On Tuesday, 13 December 2016 at 23:29:31 UTC, Ali Çehreli wrote: On 12/13/2016 01:36 PM, Ali wrote: Now about that second part of my problem I'm not entirely sure whether this should work but I think the problem is with mutating the 'frequencies' member of an immutable element of 'rooms'. The error message means that those non-const expressions cannot be shared by a member of an immutable AA. I'm not sure I fully follow here. Because the variable in the parse function is not immutable and the frequencies member is not "created" yet, so to say. So after I create the frequencies object, I assign it to the member of a Room object. The following illustrates this more clearly I think: struct A { int x; } struct B { int[char] x; } auto f1() { int x; x = 3; return A(x); } auto f2() { int[char] x; x['A'] = 2; return B(x); } static immutable a = f1(); static immutable b = f2(); pragma(msg, a); pragma(msg, b); This fails to compile with "Error: non-constant expression ['A':2]". But, the pragma(msg) prints out the correct information for both a and b. What's the deal with static immutable associative arrays and D anyway? Is there some kind of roadmap somewhere or bugs that need to be fixed before they work properly in D? I'm confused because it seems like the data actually gets inside the struct object that has an AA as a member, but then the compiler just decides "nah, just kidding, this ain't actually ok. bye". I moved the frequencies to 'data' and hte following worked. Yeah that is indeed the workaround I mentioned and hence the need for the pointer to room problem I was having :p This does work. But I guess I'm just looking for a more ideal solution. Thanks for all the help so far! :)
Issue with dmd, linker, visualD on windows 10
I am trying to get a fellow to try D but just setting up on windows 10 has been headache. He's currently remote. Here's the problem. (Note I'm a Linux user and haven't used windows 10) 1. He installed dmd 2 but the command "dmd" is not recognized. He confirmed and c:\D\dmd2\windows\bin is in system path. Why? 2. He installed visual studio 2015 and visualD(pointed it to dmd location during installation), restarted visual studio. Without creating a visualD project, "compile and run" does nothing when he clicks. We haven't tried creating a project though, just using a D file with simple "Hello, world!" code. Syntax highlighting work though. 3. He navigated to ...dmd2\windows\bin where "dmd" command works. But "dmd -run file.d" says Oplink error, linker exited with code ...
Re: Issue with dmd, linker, visualD on windows 10
On 15/12/2016 12:06 AM, aberba wrote: I am trying to get a fellow to try D but just setting up on windows 10 has been headache. He's currently remote. Here's the problem. (Note I'm a Linux user and haven't used windows 10) 1. He installed dmd 2 but the command "dmd" is not recognized. He confirmed and c:\D\dmd2\windows\bin is in system path. Why? Environment variables don't auto update in Windows. Gotta logout/restart explorer/restart or even create a new terminal instance with no parent processes. 2. He installed visual studio 2015 and visualD(pointed it to dmd location during installation), restarted visual studio. Without creating a visualD project, "compile and run" does nothing when he clicks. We haven't tried creating a project though, just using a D file with simple "Hello, world!" code. Syntax highlighting work though. 3. He navigated to ...dmd2\windows\bin where "dmd" command works. But "dmd -run file.d" says Oplink error, linker exited with code ... File please oh and output during the running of dmd including of the linker.
Re: rtInfo()
On 14/12/2016 11:52 PM, Satoshi wrote: Hello, is rtInfo() already used by GC? I need to store some data for each class so I'm using this template and m_rtInfo in TypeInfo_Class but now it seems that GC is not working properly in some cases. Thanks. Doesn't look like it. https://github.com/dlang/druntime/search?utf8=%E2%9C%93=rtInfo Remember rtInfo is per class definition, not instance. If you really need to modify rtInfo, don't do it directly. TypeInfo is meant to be read only. Do it via the RTInfo template[0] but that means modifying druntime. [0] https://github.com/dlang/druntime/blob/ce0f089fec56f7ff5b1df689f5c81256218e415b/src/object.d#L3230
Re: Question about compile-time functions.
On Wednesday, 14 December 2016 at 07:15:08 UTC, Bauss wrote: If a function is only called during compile-time will it be available at runtime? With "available at runtime", I guess you mean "will it be part of the object file". In that case: yes. Because even if a function is _never_ called, it will be part of the object file (it must be). For templated functions, the answer is not so easy. Templates that are only instantiated during CTFE are usually also emitted into the object file. But, when importing a templated function from another module, the template instantiation is not emitted to the object file if the compiler deduces that the instantiation is already emitted in the object file result of compiling the imported module (to avoid unnecessary duplicate instantiations across compilation units). -Johan
rtInfo()
Hello, is rtInfo() already used by GC? I need to store some data for each class so I'm using this template and m_rtInfo in TypeInfo_Class but now it seems that GC is not working properly in some cases. Thanks.
Re: Question about compile-time functions.
On Wednesday, 14 December 2016 at 07:15:08 UTC, Bauss wrote: If a function is only called during compile-time will it be available at runtime? It depends. When linking unused functions can be removed by -gc-sections, but only when linking an executable. But obviously if you use it at runtime then the linker won't remove it. If you want to ensure that it never gets called at runtime, put a `assert(__ctfe);` at the beginning of the function. There was a discussion some time ago about having an attribute(?) to disable codegen for particular functions (e.g. code for generating string for string mixins), but i'm not sure what became of that.