Re: erro when use core.runtime

[Dsby via Digitalmars-d-learn]

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

[Dsby via Digitalmars-d-learn]

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

[Dsby via Digitalmars-d-learn]

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

[Nordlöw via Digitalmars-d-learn]

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

[H. S. Teoh via Digitalmars-d-learn]

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

[Per Nordlöw via Digitalmars-d-learn]

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

[Per Nordlöw via Digitalmars-d-learn]

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

[Igor via Digitalmars-d-learn]

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

[Marco Leise via Digitalmars-d-learn]

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

[Jerry via Digitalmars-d-learn]

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

[Igor via Digitalmars-d-learn]

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

[solidstate1991 via Digitalmars-d-learn]

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

[Igor via Digitalmars-d-learn]

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

[Igor via Digitalmars-d-learn]

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?

[Patric Dexheimer via Digitalmars-d-learn]

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

[Jonathan M Davis via Digitalmars-d-learn]

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?

[Adam D. Ruppe via Digitalmars-d-learn]

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

[Andrew Godfrey via Digitalmars-d-learn]

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?

[Patric Dexheimer via Digitalmars-d-learn]

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?

[via Digitalmars-d-learn]

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?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

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?

[bauss via Digitalmars-d-learn]

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();
spawn();
}

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.