Re: erro when use core.runtime
I am in openSUSE. I see the code in runtime. it is only support Windows in default. in posix only version (Shared) is will build. why?
Re: erro when use core.runtime
On Thursday, 18 May 2017 at 04:53:36 UTC, Dsby wrote: Linking... ../../.dub/build/library-debug-linux.posix-x86_64-dmd_2073-368A963AFD76168526BD99BBB313FD4B/libyu.a(runtime_a21_4e7.o):在函数‘_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv ’中: /usr/include/dmd/druntime/import/core/runtime.d:222:对‘rt_loadLibrary’未定义的引用 ../../.dub/build/library-debug-linux.posix-x86_64-dmd_2073-368A963AFD76168526BD99BBB313FD4B/libyu.a(runtime_a22_5ca.o):在函数‘_D4core7runtime7Runtime19__T13unloadLibraryZ13unloadLibraryFPv Zb’中: /usr/include/dmd/druntime/import/core/runtime.d:237:对‘rt_unloadLibrary’未定义的引用 it is in 2.073.1 it is also error in ldc 1.1.0 (dmd 2.071.2)
erro when use core.runtime
Linking... ../../.dub/build/library-debug-linux.posix-x86_64-dmd_2073-368A963AFD76168526BD99BBB313FD4B/libyu.a(runtime_a21_4e7.o):在函数‘_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv ’中: /usr/include/dmd/druntime/import/core/runtime.d:222:对‘rt_loadLibrary’未定义的引用 ../../.dub/build/library-debug-linux.posix-x86_64-dmd_2073-368A963AFD76168526BD99BBB313FD4B/libyu.a(runtime_a22_5ca.o):在函数‘_D4core7runtime7Runtime19__T13unloadLibraryZ13unloadLibraryFPv Zb’中: /usr/include/dmd/druntime/import/core/runtime.d:237:对‘rt_unloadLibrary’未定义的引用 it is in 2.073.1
Re: Atomicity of file-copying/moving
On Wednesday, 17 May 2017 at 20:02:44 UTC, Per Nordlöw wrote: The standard way is to copy the source to a temporary file on the same file system as the target file followed by hardlinking Correction: should be renaming. Here's an implementation in Python (3): https://github.com/nordlow/containerize/blob/1dbcf57c1240882f8492f261962df0dfaa4edecb/containerize.py#L132 I would like to have it in D too. Any advice regarding the port?
Re: Atomicity of file-copying/moving
On Wed, May 17, 2017 at 07:56:52PM +, Per Nordlöw via Digitalmars-d-learn wrote: > On Tuesday, 16 May 2017 at 10:57:08 UTC, FreeSlave wrote: > > > > Not sure about renaming but copying is not atomic on Posix because > > it does not handle interruption by signal. I opened issue about that > > https://issues.dlang.org/show_bug.cgi?id=17296 > > The standard way is to copy the source to a temporary file on the same > file system as the target file followed by hardlinking the temporary > to the target file. If an error occurs during copying you either retry > or abort. That should be atomic. Unfortunately it does suffer from the limitation that if the file is large, you may run out of space on the target filesystem where you may not have, had you overwritten the target file directly. But I suppose it's an acceptable tradeoff where atomicity of copying is desired. T -- "The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."
Re: Atomicity of file-copying/moving
On Wednesday, 17 May 2017 at 19:56:52 UTC, Per Nordlöw wrote: On Tuesday, 16 May 2017 at 10:57:08 UTC, FreeSlave wrote: Not sure about renaming but copying is not atomic on Posix because it does not handle interruption by signal. I opened issue about that https://issues.dlang.org/show_bug.cgi?id=17296 The standard way is to copy the source to a temporary file on the same file system as the target file followed by hardlinking Correction: should be renaming.
Re: Atomicity of file-copying/moving
On Tuesday, 16 May 2017 at 10:57:08 UTC, FreeSlave wrote: Not sure about renaming but copying is not atomic on Posix because it does not handle interruption by signal. I opened issue about that https://issues.dlang.org/show_bug.cgi?id=17296 The standard way is to copy the source to a temporary file on the same file system as the target file followed by hardlinking the temporary to the target file. If an error occurs during copying you either retry or abort. That should be atomic.
Re: How to setup DLL and EXE projects in one VS solution
On Wednesday, 17 May 2017 at 18:03:04 UTC, Igor wrote: What exactly do mean by "binding"? If I understand the rest you are saying that I could just use "Add existing item" to add the dllproj.d file to EXEProject as well, but that would cause all of the code from it to be linked in the EXE and I only want that code in the DLL. I should also mention that I don't want to statically bind to DLL using a lib file because I want to be able to reload the DLL while the application is running. I managed to get it to work by extracting all common structs to dllprojInterface.d module that sits at /source/dllprojInterface.d on the file system but is added to both projects in the solution. I am still wondering if there is a better solution? Also I am wondering if using extern(C) as opposed to extern(D) only affects name mangling or am I losing some DLang possibilities since I am only calling DLang DLL from DLang EXE?
Re: avoid extra variable during void pointer cast
Am Mon, 15 May 2017 19:30:00 + schrieb Bauss : > pragma(inline, true); doesn't actually do what you think it does. > In lining is always done whenever possible and that only tells > the compiler to spit out an error if it can't inline it. A compiler doesn't simply inline whenever it can. A big function that's called often would lead to massive code duplication in that case. What I meant pragma(inline, true) to do is overrule this cost calculation. Since the OP asked for no extra function calls, the error on failure to inline seemed appropriate. Cross-module inlining may fail for example on some compiler(s) or with separate compilation. -- Marco
Re: Atomicity of file-copying/moving
On Tuesday, 16 May 2017 at 08:32:56 UTC, Nordlöw wrote: What's the status of atomicity of file-copying and -moving (renaming) using std.file on different platforms? Niall has a good talk about this on youtube: https://www.youtube.com/watch?v=uhRWMGBjlO8
Re: How to setup DLL and EXE projects in one VS solution
On Wednesday, 17 May 2017 at 17:48:50 UTC, solidstate1991 wrote: I think you should make a binding for your DLL file. On the other hand I successfully set up a static library and an application in the same solution (now it has 2 apps, one is my map editor and file converter, the other is a window layout editor, going to add a third one for testing other functions later on) by adding the engine's sources and library files to the app. What exactly do mean by "binding"? If I understand the rest you are saying that I could just use "Add existing item" to add the dllproj.d file to EXEProject as well, but that would cause all of the code from it to be linked in the EXE and I only want that code in the DLL. I should also mention that I don't want to statically bind to DLL using a lib file because I want to be able to reload the DLL while the application is running.
Re: How to setup DLL and EXE projects in one VS solution
On Wednesday, 17 May 2017 at 16:56:13 UTC, Igor wrote: At the moment I have: EXEProject: app.d - it does loadlibrary of dllproj and uses data structures defined in dllproj.d (it imports dllproj). On the file system this file is under /platform/win32/ and is defined as module win32.app; DLLProject dllproj.d - exports functions and contains data structures those function use. On file system this file is under /source and is defined as module dllproj; EXEProject depends on DLLProject. DLL project compiles and builds DLL fine but, of course EXE project breaks with an error: module dllproj is in file dllproj.d which cannot be read. I could just copy all the structs from dllproj.d to app.d and remove the import and I guess it would all work but there has to be a better way to structure code so structs are only written in one place? I think you should make a binding for your DLL file. On the other hand I successfully set up a static library and an application in the same solution (now it has 2 apps, one is my map editor and file converter, the other is a window layout editor, going to add a third one for testing other functions later on) by adding the engine's sources and library files to the app.
How to setup DLL and EXE projects in one VS solution
At the moment I have: EXEProject: app.d - it does loadlibrary of dllproj and uses data structures defined in dllproj.d (it imports dllproj). On the file system this file is under /platform/win32/ and is defined as module win32.app; DLLProject dllproj.d - exports functions and contains data structures those function use. On file system this file is under /source and is defined as module dllproj; EXEProject depends on DLLProject. DLL project compiles and builds DLL fine but, of course EXE project breaks with an error: module dllproj is in file dllproj.d which cannot be read. I could just copy all the structs from dllproj.d to app.d and remove the import and I guess it would all work but there has to be a better way to structure code so structs are only written in one place?
Re: Current LDC Android status
On Tuesday, 16 May 2017 at 03:00:08 UTC, Mike B Johnson wrote: So what is currently the state of affairs with LDC and android? Last time I remember, it *could* compile to android but barely. About a month ago I tried to build OpenGL sample app following directions from here: https://wiki.dlang.org/Build_LDC_for_Android but I used these samples to see how to configure the project in latest Android Studio which includes .so file compiled from D and nothing else: https://github.com/googlesamples/android-ndk/tree/master/hello-libs and it worked. I used Ubuntu bash on Windows to do it. It is not too complicated but is certainly not straightforward and I am also looking forward to having all this nicely integrated in one official compiler that would just work.
Re: function overload with mixin template bug?
On Wednesday, 17 May 2017 at 13:26:36 UTC, Adam D. Ruppe wrote: On Wednesday, 17 May 2017 at 13:13:06 UTC, Patric Dexheimer wrote: Function overloads coming from mixin templates are not being detected ? A name being present in the struct means that name is NOT pulled from the mixin template. This is a feature, not a bug. It allows overriding of mixin template individual behavior. see: http://arsdnet.net/this-week-in-d/sep-27.html To bring in the mixin overloads in addition to your current ones instead of overriding, use alias: mixin Foo some_name; alias foo = some_name.foo; void foo() {} // now they are all combined Oh, thank you, didn´t know about it. didn´t know about this syntax also "mixin Foo some_name;"
Re: No tempFile() in std.file
On Wednesday, May 17, 2017 05:34:50 Patrick Schluter via Digitalmars-d-learn wrote: > On Wednesday, 17 May 2017 at 05:30:40 UTC, Patrick Schluter wrote: > > On Tuesday, 16 May 2017 at 13:56:57 UTC, Jonathan M Davis wrote: > >> [...] > > > > As your solution doesn't inherently solve the race condition > > associated with temporary files, you could still generate the > > name with a wrapper around tempnam() or tmpnam() (Posix for > > Windows I don't know). This would avoid the double open() of > > the scenario above. > > But as Jonathan said above, this is not a good solution in any > case. In Posix the use the mks*temp() family of functions is > standard now. As I recall, the main problem with mks*temp() is that some platforms only support a stupidly short list af random values (something like 26 IIRC). Regardless, it's trivial to write that functionality yourself. The key is that you open the file with the flag that indicates that the file must not exist when you open it. Worst case, you have to try a few times with different file names, but if you generate something like a UUID, then the odds of a collision are so low that that's not realistically an issue. And AFAIK, for mks*temp() to guarantee that the file was created by the call, it has to do basically the same thing internally. But in any case, even if we wanted to use mks*temp() in a D program, we'd want to wrap it in a portable D function using D's strings and not char*. So, whether mks*temp() is used is an implementation detail. For the use case where you actually want a file name rather than just a file handle to play around with, you're almost certainly going to be closing and reopening the file or closing it and handing its path off to another program, in which case, the only real downside to having a function that securely creates an empty temporary file and returns its path is that you then have to open it a second time to put actual data in it, whereas a function like scratchFile lets you start writing to it without opening it again. Regardless, as long as a program can get the path to the file, and has the appropriate permissions, as I understand it, there's a risk of them screwing with it even if you have it open (at least on POSIX systems which don't normally use file locks and where - as I understand it - obeying the file locks is completely optional, unlike Windows which likes to lock everything). So, while having scratchFile would definitely be nice, maybe a good solution would be to add function to std.file such as writeToTempFile which acted like std.file.write except that it created a temporary file which was guaranteed to not exist prior to the call and returned its path after it wrote to it. If you want to use std.stdio.File with it, you're still forced to write an empty file and then open it again with File, but for the case where you simply want to write the data to a file and then pass the path to something else to use it (be it something in your program or another program), it should work well. Certainly, it would be far better than what we have now (which would be nothing). So, I should probably dig up my scratchFile implementation and adapt it for std.file as something like writeToTempFile or createTempFile. - Jonathan M Davis
Re: function overload with mixin template bug?
On Wednesday, 17 May 2017 at 13:13:06 UTC, Patric Dexheimer wrote: Function overloads coming from mixin templates are not being detected ? A name being present in the struct means that name is NOT pulled from the mixin template. This is a feature, not a bug. It allows overriding of mixin template individual behavior. see: http://arsdnet.net/this-week-in-d/sep-27.html To bring in the mixin overloads in addition to your current ones instead of overriding, use alias: mixin Foo some_name; alias foo = some_name.foo; void foo() {} // now they are all combined
Re: Atomicity of file-copying/moving
On Tuesday, 16 May 2017 at 08:32:56 UTC, Nordlöw wrote: What's the status of atomicity of file-copying and -moving (renaming) using std.file on different platforms? For renaming that's a good question, but for copying, no-one should make atomicity guarantees. It's inherently non-atomic, and if you try to build an atomic wrapper around it (by trying to catch failure cases and deleting the file), you'd be ignoring cases like power failure, system hang, process crash. Some of those could be achieved on some OSes, but I doubt all of them can on all OSes.
function overload with mixin template bug?
1) struct T{ void f1(){writeln("default f1");} void f1(int x){writeln("overload f1");} } //main T().f1(); T().f1(1); //compiles and output as expected. 2) mixin template add_function(){ void f1(){writeln("default f1");} } struct T{ mixin add_function; void f1(int x){writeln("overload f1");} } //main T().f1(); T().f1(1); //Error: function f355.T.f1 (int x) is not callable using argument types () /* What? i´m missing something here? */ 3) mixin template add_function(){ void f1(){writeln("default f1");} } struct T{ mixin add_function; } //main T().f1(); //compiles and output as expected. Function overloads coming from mixin templates are not being detected ?
Re: D equivalent of C++11's function local static initialization?
On Wednesday, 17 May 2017 at 03:08:39 UTC, Timothee Cour wrote: NOTE: curious about both cases: * thread local * shared On Tue, May 16, 2017 at 8:04 PM, Timothee Cour wrote: what's the best D equivalent of C++11's function local static initialization? ``` void fun(){ static auto a=[](){ //some code return some_var; } } ``` (C++11 guarantees thread safety) In D this is a library construct, instead of built into the language. See http://dlang.org/phobos-prerelease/std_concurrency#.initOnce.
Re: D equivalent of C++11's function local static initialization?
On Wednesday, 17 May 2017 at 07:08:07 UTC, bauss wrote: On Wednesday, 17 May 2017 at 03:08:39 UTC, Timothee Cour wrote: NOTE: curious about both cases: * thread local * shared On Tue, May 16, 2017 at 8:04 PM, Timothee Cour wrote: what's the best D equivalent of C++11's function local static initialization? ``` void fun(){ static auto a=[](){ //some code return some_var; } } ``` (C++11 guarantees thread safety) I don't know the exact equivalent, mostly because I don't really know what the C++ statement does tbh. Tried to look it up real quick, but can't seem to find anything actual information on it. It initializes a global variable "a" once from an unnamed class object with a "opCall" style method on it. Lambdas in C++ are regular objects with some syntactical sugar over it. http://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables «If multiple threads attempt to initialize the same static local variable concurrently, the initialization occurs exactly once (similar behavior can be obtained for arbitrary functions with std::call_once). Note: usual implementations of this feature use variants of the double-checked locking pattern, which reduces runtime overhead for already-initialized local statics to a single non-atomic boolean comparison.»
Re: D equivalent of C++11's function local static initialization?
On Wednesday, 17 May 2017 at 03:08:39 UTC, Timothee Cour wrote: NOTE: curious about both cases: * thread local * shared On Tue, May 16, 2017 at 8:04 PM, Timothee Cour wrote: what's the best D equivalent of C++11's function local static initialization? ``` void fun(){ static auto a=[](){ //some code return some_var; } } ``` (C++11 guarantees thread safety) I don't know the exact equivalent, mostly because I don't really know what the C++ statement does tbh. Tried to look it up real quick, but can't seem to find anything actual information on it. However I can answer about thread local and shared. Every global is per standard thread local in D. For example: int foo; void fun() { foo++; writeln(foo); } void main() { spawn(&fun); spawn(&fun); } In D the output is: 1 1 However in other languages that doesn't have thread-local per standard the output may vary depending on race-conditions. So it could be: 1 1 Or: 1 2 Then there's shared. Shared is kind of a bottle-neck to use and if you're going to use it you should write all your code as shared and synchronized from the beginning else you'll just end up ripping your hair out. shared variables are required to be used in synchronized contexts, that's about it. It sounds simple, but implementing it properly is not that easy and tends to just be a bothersome in exchange for other safe implementation On the contrary to shared, there's __gshared which is basically the equivalent to plain old globals in C.