Re: Memory allocation failed. Why?

2016-11-20 Thread Stefan Koch via Digitalmars-d-learn

On Monday, 21 November 2016 at 06:45:04 UTC, ag0aep6g wrote:

On 11/21/2016 07:36 AM, Stefan Koch wrote:

On Monday, 21 November 2016 at 03:58:00 UTC, MGW wrote:

On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:

On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:

[...]

[...]

You are appending 100_000_000 Times.
Note that this will take up much more then 100 MB.
Because the allocator cannot always grow the array.
All previously allocated blocks are still in scope and could 
be reached.

Therefore the memory is not released.


How could they be reached? The only reference is `buf', and 
when appending triggers relocation, `buf` should point to the 
new location, no?


Someone could still be hanging on to an old Reference of buf.



Re: Memory allocation failed. Why?

2016-11-20 Thread ag0aep6g via Digitalmars-d-learn

On 11/21/2016 07:36 AM, Stefan Koch wrote:

On Monday, 21 November 2016 at 03:58:00 UTC, MGW wrote:

On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:

On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:

import core.sys.windows.windows: MessageBoxA;

void test() {
for(int i; i != 10; i++) {
ubyte[] buf;
for(int j; j != 1; j++) buf ~= 65;
MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
// delete buf; // if ON - then memory delete in step
}
MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
}

void main() {
test();
MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
}

[...]

You are appending 100_000_000 Times.
Note that this will take up much more then 100 MB.
Because the allocator cannot always grow the array.
All previously allocated blocks are still in scope and could be reached.
Therefore the memory is not released.


How could they be reached? The only reference is `buf', and when 
appending triggers relocation, `buf` should point to the new location, no?


Re: Memory allocation failed. Why?

2016-11-20 Thread Stefan Koch via Digitalmars-d-learn

On Monday, 21 November 2016 at 03:58:00 UTC, MGW wrote:

On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:

On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:

import core.sys.windows.windows: MessageBoxA;

void test() {
for(int i; i != 10; i++) {
ubyte[] buf;
for(int j; j != 1; j++) buf ~= 65;
MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
// delete buf; // if ON - then memory delete in step
}
MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
}

void main() {
test();
MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
}


core.exception.OutOfMemoryError@src\core\exception.d(693): 
Memory allocation failed




This short program doesn't work at Windows 32. Why GC doesn't 
release memory in case of its shortage in Windows! This is bug?


You are appending 100_000_000 Times.
Note that this will take up much more then 100 MB.
Because the allocator cannot always grow the array.
All previously allocated blocks are still in scope and could be 
reached.

Therefore the memory is not released.

At least this is what I think happens.
it would help more if you could post the specs of your machine 
and what else is running on it.


Re: Memory allocation failed. Why?

2016-11-20 Thread MGW via Digitalmars-d-learn

On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:

On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:

import core.sys.windows.windows: MessageBoxA;

void test() {
for(int i; i != 10; i++) {
ubyte[] buf;
for(int j; j != 1; j++) buf ~= 65;
MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
// delete buf; // if ON - then memory delete in step
}
MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
}

void main() {
test();
MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
}


core.exception.OutOfMemoryError@src\core\exception.d(693): 
Memory allocation failed




This short program doesn't work at Windows 32. Why GC doesn't 
release memory in case of its shortage in Windows! This is bug?


Re: Memory allocation failed. Why?

2016-11-20 Thread Nicholas Wilson via Digitalmars-d-learn

On Sunday, 20 November 2016 at 18:58:04 UTC, Basile B. wrote:

On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:

[...]


For me there's no exception. Maybe the GC is poluted. Try to 
add this after each iteration in the first test loop:


import core.memory: GC;
GC.collect();

Also note that the text you pas in the message box should be 
null terminated, eg:


MessageBoxA(null, "--The end--\0".ptr, "".ptr, 0);


string literals are implicitly null terminated explicitly for the 
interoperation with C.

there is no need.


Re: Making floating point deterministic cross diffrent platforms/hardware

2016-11-20 Thread Guillaume Piolat via Digitalmars-d-learn

On Sunday, 20 November 2016 at 22:36:12 UTC, Chainingsolid wrote:
I'm making an rts so the client/server model would require very 
unrealistic bandwidth, hence the lock step peer to peer system.


Indeed, peer to peer require determinism I guess.




Re: Making floating point deterministic cross diffrent platforms/hardware

2016-11-20 Thread Ilya Yaroshenko via Digitalmars-d-learn

On Sunday, 20 November 2016 at 21:42:30 UTC, ketmar wrote:
On Sunday, 20 November 2016 at 21:31:09 UTC, Guillaume Piolat 
wrote:
I think you can roughly have that with ldc, always using SSE 
and the same rounding-mode.


ARM. oops.


No problem with ARM + x86 for double and float.


Re: Making floating point deterministic cross diffrent platforms/hardware

2016-11-20 Thread Chainingsolid via Digitalmars-d-learn
On Sunday, 20 November 2016 at 21:31:09 UTC, Guillaume Piolat 
wrote:
If you use client prediction, and the server (authoritative) 
sends the correct player position to clients regularly (action 
game), then no determinism is actually needed. Ask Manu who 
knows more about this.


I'm making an rts so the client/server model would require very 
unrealistic bandwidth, hence the lock step peer to peer system.


Re: Making floating point deterministic cross diffrent platforms/hardware

2016-11-20 Thread ketmar via Digitalmars-d-learn
On Sunday, 20 November 2016 at 21:31:09 UTC, Guillaume Piolat 
wrote:
I think you can roughly have that with ldc, always using SSE 
and the same rounding-mode.


ARM. oops.


Re: Making floating point deterministic cross diffrent platforms/hardware

2016-11-20 Thread Guillaume Piolat via Digitalmars-d-learn

On Sunday, 20 November 2016 at 19:12:06 UTC, Chainingsolid wrote:
I planning out a game that has to use a lock step, peer to peer 
networking model to achieve multiplayer, and thus I need to 
have any floating point used produce the exact same results, no 
matter what, aka be completely deterministic. What would I need 
to do to achieve this?


I think you can roughly have that with ldc, always using SSE and 
the same rounding-mode. If you use the FPU then the excess 
precision will make things diverge.
I've not compared the results across OSes but I get the exact 
same results across 32-bit and 64-bit.


Another way for deterministic FP is to round to a lower 
precision, or used fixed-point/integers.


If you use client prediction, and the server (authoritative) 
sends the correct player position to clients regularly (action 
game), then no determinism is actually needed. Ask Manu who knows 
more about this.


Re: shared arrray problem

2016-11-20 Thread ag0aep6g via Digitalmars-d-learn

On 11/20/2016 09:09 PM, Charles Hixson via Digitalmars-d-learn wrote:

Thinking it over a bit more, the item returned would need to be a
struct, but the struct wouldn't contain the array, it would just contain
a reference to the array and a start and end offset.  The array would
need to live somewhere else, in the class (or struct...but class is
better as you don't want the array evaporating by accident) that created
the returned value.  This means you are dealing with multiple levels of
indirection, so it's costly compared to array access, but cheap compared
to lots of large copies.  So the returned value would be something like:
struct
{
private:
/** this is a reference to the data that lives elsewhere.  It should
be a pointer, but I don't like the syntax*/
ubyte[]  data;
intstart, end;///first and last valid indicies into data
public:
this (ubyte[] data, int start, int end)
{this.data = data; this.start = start; this.end = end;}
...
// various routines to access the data, but to limit the access to
the spec'd range, and
// nothing to change the bounds
}


Instead of extra 'start' and 'end' fields you can slice the array. A 
dynamic array already is just a reference coupled with a length, i.e. a 
pointer with restricted indexing. So you can slice the original array 
with your offsets and create the struct with that slice.


I feel like there is a misunderstanding somewhere, but I'm not sure on 
whose side. As far as I can tell, your understanding of dynamic arrays 
may be lacking, or maybe I don't understand what you're getting at.



Which is really the answer you already posted, but just a bit more
detail on the construct, and what it meant.  (Yeah, I could allow types
other than ubyte as the base case, but I don't want to.  I'm thinking of
this mainly as a means of sharing a buffer between applications where
different parts have exclusive access to different parts of the buffer,
and where the buffer will be written to a file with a single fwrite, or
since the underlying storage will be an array, it could even be
rawwrite).  I don't want to specify any more than I must about how the
methods calling this will format the storage, and this means that those
with access to different parts may well use different collections of
types, but all types eventually map down to ubytes (or bytes), so ubytes
is the common ground.  Perhaps I'll need to write inbuffer,outbuffer
methods/wrappings, but that's far in the future.


Sure, go with a specialized type instead of a template, if that makes 
more sense for your use case. As far as I see, the concept is 
independent of the element type, so it seemed natural to make it a 
template, but a special type is perfectly fine and probably has less 
pitfalls.



P.S.:  The traits that I mentioned previously were those given by:
static assert(!__traits(compiles, cla.length = 3));
static assert(!__traits(compiles, cla ~= 6));
in your main routine.  I assumed that they were validity tests.  I don't
understand why they were static.  I've never happened to use static
asserts, but I would assume that when they ran cla wouldn't be defined.


Those are tests to ensure that cla's length cannot be set and that it 
cannot be appended to. The asserts check that the code does not compile, 
i.e. that you cannot do those things. They're static simply because they 
can be. The code inside is not executed at run-time.




Re: shared arrray problem

2016-11-20 Thread Charles Hixson via Digitalmars-d-learn

On 11/20/2016 03:42 AM, ag0aep6g via Digitalmars-d-learn wrote:

On 11/20/2016 04:34 AM, Charles Hixson via Digitalmars-d-learn wrote:

Whether you would call the change "break things for your code" might be
dubious.  It would be effectively broken, even if technically my code
was doing the correct thing.  But my code wouldn't be storing the data
that needed storing, so effectively it would be broken.


I don't see how it's dubious. It's an error by the user. When users 
are given a dynamic array (and not by reference), they cannot expect 
that your code sees changes to length. That's just not how arrays 
work. When a user has that wrong expectation, and writes wrong code 
because of it, then it's arguably their own fault. However, if you 
want you can hold their hand a bit and make the mistake less likely.



"Write something
for yourself" is what I'd like to do, given that the language doesn't
have that built-in support, but I can't see how to do it.


Wrap the array in a struct that has indexing, but doesn't allow 
setting the length or appending. Here's a quick prototype:



struct ConstLengthArray(E)
{
private E[] data;
this(E[] arr) { this.data = arr; }
ref inout(E) opIndex(size_t i) inout { return data[i]; }
@property size_t length() const { return data.length; }
}

void main()
{
auto cla = ConstLengthArray!ubyte([1, 2, 3, 4, 5]);

/* Mutating elements is allowed: */
cla[0] = 10;
assert(cla[0] == 10);

/* No setting length, no appending: */
static assert(!__traits(compiles, cla.length = 3));
static assert(!__traits(compiles, cla ~= 6));
}


You might want to add support for slicing, concatenation, etc. Maybe 
allow implicit conversion to const(E[]), though that would also allow 
conversion to const(E)[] and that has a settable length again
Thinking it over a bit more, the item returned would need to be a 
struct, but the struct wouldn't contain the array, it would just contain 
a reference to the array and a start and end offset.  The array would 
need to live somewhere else, in the class (or struct...but class is 
better as you don't want the array evaporating by accident) that created 
the returned value.  This means you are dealing with multiple levels of 
indirection, so it's costly compared to array access, but cheap compared 
to lots of large copies.  So the returned value would be something like:

struct
{
private:
/** this is a reference to the data that lives elsewhere.  It 
should be a pointer, but I don't like the syntax*/

ubyte[]  data;
intstart, end;///first and last valid indicies into data
public:
this (ubyte[] data, int start, int end)
{this.data = data; this.start = start; this.end = end;}
...
// various routines to access the data, but to limit the access to 
the spec'd range, and

// nothing to change the bounds
}
Which is really the answer you already posted, but just a bit more 
detail on the construct, and what it meant.  (Yeah, I could allow types 
other than ubyte as the base case, but I don't want to.  I'm thinking of 
this mainly as a means of sharing a buffer between applications where 
different parts have exclusive access to different parts of the buffer, 
and where the buffer will be written to a file with a single fwrite, or 
since the underlying storage will be an array, it could even be 
rawwrite).  I don't want to specify any more than I must about how the 
methods calling this will format the storage, and this means that those 
with access to different parts may well use different collections of 
types, but all types eventually map down to ubytes (or bytes), so ubytes 
is the common ground.  Perhaps I'll need to write inbuffer,outbuffer 
methods/wrappings, but that's far in the future.


P.S.:  The traits that I mentioned previously were those given by:
static assert(!__traits(compiles, cla.length = 3));
static assert(!__traits(compiles, cla ~= 6));
in your main routine.  I assumed that they were validity tests.  I don't 
understand why they were static.  I've never happened to use static 
asserts, but I would assume that when they ran cla wouldn't be defined.


N.B.:  Even this much is just thinking about design, not something I'll 
actually do at the moment.  But this is a problem I keep coming up 
against, so a bit of thought now seemed a good idea.


Re: How to correct share data between threads?

2016-11-20 Thread Nicolas Gurrola via Digitalmars-d-learn
On Sunday, 20 November 2016 at 17:50:38 UTC, Konstantin 
Kutsevalov wrote:
Ok, thank you. But I cannot to find good example. May be you 
know some good article about it?


The Phobos documentation is a good place to start, as it has 
examples as well as the documentation for all the APIs: 
https://dlang.org/phobos/std_concurrency.html and 
https://dlang.org/phobos/std_parallelism.html. For something more 
in depth, the chapter on concurrency from TDPL is available 
online, which covers std.concurrency: 
http://www.informit.com/articles/article.aspx?p=1609144. And Ali 
Çehreli's book is also available online, with chapters on 
std.parallelism (http://ddili.org/ders/d.en/parallelism.html) and 
std.concurrency (http://ddili.org/ders/d.en/concurrency.html).


Re: Making floating point deterministic cross diffrent platforms/hardware

2016-11-20 Thread ketmar via Digitalmars-d-learn
write your own software fp library. this is the only way to cover 
all your broad cases.


Re: shared arrray problem

2016-11-20 Thread ag0aep6g via Digitalmars-d-learn

On 11/20/2016 08:30 PM, Charles Hixson via Digitalmars-d-learn wrote:

Well, that precise approach wouldn't work.  (The traits aren't a part of
the sturct, e.g.),


What do you mean by "traits"?


Re: shared arrray problem

2016-11-20 Thread Charles Hixson via Digitalmars-d-learn

On 11/20/2016 03:42 AM, ag0aep6g via Digitalmars-d-learn wrote:

On 11/20/2016 04:34 AM, Charles Hixson via Digitalmars-d-learn wrote:

Whether you would call the change "break things for your code" might be
dubious.  It would be effectively broken, even if technically my code
was doing the correct thing.  But my code wouldn't be storing the data
that needed storing, so effectively it would be broken.


I don't see how it's dubious. It's an error by the user. When users 
are given a dynamic array (and not by reference), they cannot expect 
that your code sees changes to length. That's just not how arrays 
work. When a user has that wrong expectation, and writes wrong code 
because of it, then it's arguably their own fault. However, if you 
want you can hold their hand a bit and make the mistake less likely.



"Write something
for yourself" is what I'd like to do, given that the language doesn't
have that built-in support, but I can't see how to do it.


Wrap the array in a struct that has indexing, but doesn't allow 
setting the length or appending. Here's a quick prototype:



struct ConstLengthArray(E)
{
private E[] data;
this(E[] arr) { this.data = arr; }
ref inout(E) opIndex(size_t i) inout { return data[i]; }
@property size_t length() const { return data.length; }
}

void main()
{
auto cla = ConstLengthArray!ubyte([1, 2, 3, 4, 5]);

/* Mutating elements is allowed: */
cla[0] = 10;
assert(cla[0] == 10);

/* No setting length, no appending: */
static assert(!__traits(compiles, cla.length = 3));
static assert(!__traits(compiles, cla ~= 6));
}


You might want to add support for slicing, concatenation, etc. Maybe 
allow implicit conversion to const(E[]), though that would also allow 
conversion to const(E)[] and that has a settable length again.


Well, that precise approach wouldn't work.  (The traits aren't a part of 
the sturct, e.g.), but returning a struct (or perhaps a class) rather 
than an actual array has promise.  It could even allow separate callers 
to have separate views of the data based on some sort of registered key, 
which they could share on an as-needed basis.  That's too much overhead 
work for this project, but has promise for the more general problem.


Making floating point deterministic cross diffrent platforms/hardware

2016-11-20 Thread Chainingsolid via Digitalmars-d-learn
I planning out a game that has to use a lock step, peer to peer 
networking model to achieve multiplayer, and thus I need to have 
any floating point used produce the exact same results, no matter 
what, aka be completely deterministic. What would I need to do to 
achieve this?


Re: Memory allocation failed. Why?

2016-11-20 Thread Basile B. via Digitalmars-d-learn

On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote:

import core.sys.windows.windows: MessageBoxA;

void test() {
for(int i; i != 10; i++) {
ubyte[] buf;
for(int j; j != 1; j++) buf ~= 65;
MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
// delete buf; // if ON - then memory delete in step
}
MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
}

void main() {
test();
MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
}


core.exception.OutOfMemoryError@src\core\exception.d(693): 
Memory allocation failed



Simple program and error. Why?  Windows 7 (32) dmd 2.072.0


For me there's no exception. Maybe the GC is poluted. Try to add 
this after each iteration in the first test loop:


import core.memory: GC;
GC.collect();

Also note that the text you pas in the message box should be null 
terminated, eg:


MessageBoxA(null, "--The end--\0".ptr, "".ptr, 0);


Re: How to correct share data between threads?

2016-11-20 Thread Konstantin Kutsevalov via Digitalmars-d-learn
On Saturday, 19 November 2016 at 19:04:12 UTC, Nicolas Gurrola 
wrote:
On Saturday, 19 November 2016 at 17:29:30 UTC, Konstantin 
Kutsevalov wrote:
I need to receiving data in main thread and send its to other 
thread for processing. There is a simple (but wrong) code for 
example.

What need I to change to make it correct?


```
import std.stdio, std.string, std.array, core.thread, 
std.datetime, std.conv;


int main() {
Pumpurum pp = new Pumpurum();
Thread ppt = new Thread();
ppt.start();
while(pp.waitData())
{
// some operations may be
}
writeln("finished main");
return 0;
}

class Pumpurum
{
private string[string] Data;

private string[string] Result;

private bool _quit = false;

private int _counter = 0;

bool waitData()
{
// waits for new data and adds to Data
string key;
		string line = readln(); // just for example, in real its 
will be data from several socket connections

if (line !is null) {
if (line == "quit\n") {
this._quit = true;
return false;
}
			key = Clock.currTime().toString() ~ " " ~ 
to!string(this._counter);

this.Data[key] = line; // adds new data to "Data"
}
return true;
}

void processingData()
{
string key, value;
while(!this._quit) {
if (this.Data.length > 0) {
// todo checks the "Data" for some data, processing its 
and saves a result to "Result"

foreach (key, value; this.Data) {
writeln(value); // some processing :)
this.Result[key] = value;
this.Data.remove(key);
}
}
}
writeln("finished processing");
}

}
```

Any advice may help. Thank you.


I'd recommend using std.concurrency or std.parallelism instead 
of core.thread, as they're higher level APIs. You probably want 
to check out std.parallelism first to see if it has what you 
need. Otherwise, the generic messaging API of std.concurrency 
should be easier to use than core.thread while still being very 
flexible.


Ok, thank you. But I cannot to find good example. May be you know 
some good article about it?




Memory allocation failed. Why?

2016-11-20 Thread MGW via Digitalmars-d-learn

import core.sys.windows.windows: MessageBoxA;

void test() {
for(int i; i != 10; i++) {
ubyte[] buf;
for(int j; j != 1; j++) buf ~= 65;
MessageBoxA(null, "--on for--".ptr, "".ptr, 0);
// delete buf; // if ON - then memory delete in step
}
MessageBoxA(null, "--off for--".ptr, "".ptr, 0);
}

void main() {
test();
MessageBoxA(null, "--The end--".ptr, "".ptr, 0);
}


core.exception.OutOfMemoryError@src\core\exception.d(693): Memory 
allocation failed



Simple program and error. Why?  Windows 7 (32) dmd 2.072.0


Re: Using opApply and Attributes

2016-11-20 Thread ketmar via Digitalmars-d-learn

On Sunday, 20 November 2016 at 16:36:18 UTC, Q. Schroll wrote:
How can I have relative-@attrib functions without unnecessary 
manual overloading?



import std.traits;

auto f1(DG) (DG dg) if (isCallable!DG && Parameters!DG.length == 
1 && is(Parameters!DG[0] == int)) { // check other things here 
too, like return type

  return dg(1);
}

void main () pure {
  f1((int x) => 2*x); // ok, f1 is pure
  //f1(x => 2*x); // alas, now you have to manually specify 
argument types

}


not the best solution, of course, and you can't do that without 
templates ('cause `nothrow` or `@nogc` *can* require different 
machine code in the future).


Using opApply and Attributes

2016-11-20 Thread Q. Schroll via Digitalmars-d-learn
When using functions with delegate (or function ptr) parameters 
which should comply with some attributes, I cannot call the 
delegate in the function what makes it pretty useless (I haven't 
done research, but I claim that generally most functions taking 
delegate parameters call them).


  void f1(void delegate(int) dg) // cannot be pure ...
  {
dg(1); // ... due to this call.
  }

  void main() pure
  {
f(x => 2*x); // Error, f is impure.
  }

One has to overload the function like
  auto f(delegate(Arg arg) @attrib dg) @attrib;
  auto f(delegate(Arg arg) dg);
for each combination of attributes available (today 4, worst case 
is 16 overloads), could be more in the future.


Even worse (due to bug 15859, see [1]) overload resolution on 
opApply does not work properly. Making opApply a template is a 
real solution for various reasons (virtual functions, no type 
inference on the delegate, etc.). For opApply, using the range 
interface (empty, front, popFront) is not a real solutions either 
because opApply can be truly recursive. Those can then only have 
a range interface through generators via fibers which have an 
overhead (and make them non-@nogc).


How can I have relative-@attrib functions without unnecessary 
manual overloading?
(relative: if all called parameter delegates have it, then the 
function has it)


Generally, are relative attributes worth an enhancement?

[1] https://issues.dlang.org/show_bug.cgi?id=15859


Re: Compiling and linking libraries

2016-11-20 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 20 November 2016 at 01:01:16 UTC, Darren wrote:


Thank you for this!  Great information.

So dub dynamically "add" code from the dll into the source code 
at runtime?


No. DUB doesn't have anything to do with runtime and doesn't know 
anything about the DLLs you use. The Derelict packages all rely 
on a core package called DerelictUtil. It uses the system APIs to 
load the DLL when you call the load method on a Derelict object 
(DerelictGLFW3.load, DerelictGL3.load, etc...)


Also will I ever need to learn how to use static libraries and 
is there a reason to?


When you add any Derelict package as a dependency to your 
project, you're using a static library. That is, DerelictGLFW3 
and DerelictGL3 and all Derelict* packages are themselves 
compiled by DUB automatically when you run it on your project. 
They are configured to compile as static libraries. Since DUB 
knows your project depends on them, it hands them off to the 
compiler (which in turn passes them to the linker) for you.


You seem to be mixing some terminology up a bit. There's a 
difference between static/dynamic linking and static/dynamic 
loading. The two types of linking affect how the linker generates 
the final executable, whereas the latter two types of loading 
determine how a dynamic library is loaded at runtime.


When you link with a static library at compile time (static 
linking), the library's object code is a part of the executable. 
The linker combines it all into one package and it all gets 
loaded by the system in one go at runtime.


When you link with a dynamic library at compile time (dynamic 
linking), the linker will fix up your executable such that when 
the program is run, the system loader will notice the reference 
the linker left for the dynamic library, so it will also load the 
dynamic library into the executable's process space (static 
loading).


If you want to use a dynamic library without linking to it at 
compile time, then you have to load it manually at runtime 
(dynamic loading), which means you have to declare all of the 
library's functions as function pointers instead of using regular 
function declarations. Then, at runtime, you load the library 
into memory and then fetch the address of each function. 
Essentially, you're doing by hand what the linker and system 
loader would do for you if you had linked with the dynamic 
library at compile time.


When using any C library from D, you have to declare all of the 
functions from that library in a format D understands. That's 
your binding. If you choose to use regular function declarations, 
then you have a static binding. You can use a static binding with 
both static and dynamic libraries, but they have to be passed to 
the linker at compile time. To be clear, a static binding does 
not restrict you to using only static libraries. It gives you a 
choice, but you will always have a compile time dependency.


A dynamic binding is one in which the functions are all declared 
as pointers so that a dynamic library can be loaded manually at 
runtime. There is no link time dependency. As such, it can *only* 
be used with dynamic libraries.


Re: Complex numbers are harder to use than in C

2016-11-20 Thread Ilya Yaroshenko via Digitalmars-d-learn

On Saturday, 19 November 2016 at 19:42:27 UTC, Marduk wrote:

On Saturday, 19 November 2016 at 16:17:08 UTC, Meta wrote:

On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote:

[...]


D used to support complex numbers in the language (actually it 
still does, they're just deprecated). This code should compile 
with any D compiler:


cdouble[2][2] a = [[0 + 1i, 0], [0, 0 + 1i]];


Thank you! However, I am concerned that if this is deprecated, 
then I should not use it (it is not future-proof). I wonder why 
D dropped this syntax for complex numbers. It is very handy.


You can use builtin complex numbers (cfloat/cdouble/creal). The 
idea of std.complex is wrong . Mir GLAS uses builtin complex 
numbers and I don't think they will be really deprecated. --Ilya


Re: How to declare function with the same call signature as another?

2016-11-20 Thread Tofu Ninja via Digitalmars-d-learn

On Sunday, 20 November 2016 at 11:52:01 UTC, Tofu Ninja wrote:

...


Also does not include function linkage :/


How to access https web page using std.net.curl?

2016-11-20 Thread acbbad via Digitalmars-d-learn
I had tried std.net.curl.get (). However, the following error 
occurs


--
std.net.curl.CurlException@std\net\curl.d(4097): Peer certificate 
cannot be authenticated with given CA certificates on handle 
2175BB8

--

Guess it seems to be a problem with certificates. Can I get the 
html code of the https site using std.net.curl?


Thank you.


Re: Complex numbers are harder to use than in C

2016-11-20 Thread Marc Schütz via Digitalmars-d-learn

On Saturday, 19 November 2016 at 20:24:09 UTC, Marduk wrote:
On Saturday, 19 November 2016 at 12:55:57 UTC, Marc Schütz 
wrote:

On Saturday, 19 November 2016 at 11:11:36 UTC, Nordlöw wrote:

On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote:
The difference is that D is more verbose. Am I missing 
something? Can we have C's behaviour in D?


Something like

auto I(T)(T im)
if (isNumeric!T)
{
return complex(0, im);
}

unittest
{
auto x = 1 + 2.I;
}


Or simply:

enum I = complex(0, 1);
auto x = 1 + 2*I;


Thanks! That's a clever idea.

What I do not understand is why if I declare the array with 
Complex!double I need to complexify each entry. I would expect 
that D automatically casts 0.0 to complex(0.0).


I agree, this is unfortunate. I don't know of any reason why the 
following couldn't work in principle:


Complex!float[] arr = [1.0, 2.0, 3.0, 4.0];
// or even
auto arr = [1+2*I, 2.0, 3.0, 4.0];// compiler finds common 
type

// just like it works for
auto arr = [1, 2, 3.0, 4];// typeof(arr) is double[]

I believe it was a conscious decision. D doesn't do as many 
implicit type conversion as C++, because they often make it hard 
to understand what's going on. In the above examples though, IMO 
it wouldn't be a problem.


Re: How to declare function with the same call signature as another?

2016-11-20 Thread Tofu Ninja via Digitalmars-d-learn
On Sunday, 20 November 2016 at 11:23:37 UTC, Nicholas Wilson 
wrote:

On Sunday, 20 November 2016 at 11:19:24 UTC, Tofu Ninja wrote:
I feel like this should be simple but I can't seem to figure 
it out. How do I declare a function to have the same call 
signature as another function/callable type?


Like if I have:

alias Sig = int function(int x, int y);

How do I define a function such that it will have the same 
call signature as Sig? How do I take into account all the 
extra stuff that can go into a function signature like the 
argument attributes and the return type attributes etc.?


Another way to phrase this question would be, how do I pass a 
function signature into a template and actually define 
functions with it?


Related question, if I have Sig, how would I define DeltaSig 
to be exactly the same as Sig but with an extra parameter at 
the start or end of the parameter list?


Thanks :)

import std.traits;
ReturnType!Sig func(Parameters!Sig args)
{
//...
}


This does not seem to account for return type attributes or 
function attributes. Eg:


alias Sig = ref int function() @nogc;
ReturnType!Sig func(Parameters!Sig args) {
// func is missing ref on return type and is not @nogc
static int g;
return g;
}

How should I account for these things?



Re: Complex numbers are harder to use than in C

2016-11-20 Thread Marc Schütz via Digitalmars-d-learn

On Saturday, 19 November 2016 at 20:08:42 UTC, Marduk wrote:

On Saturday, 19 November 2016 at 11:11:36 UTC, Nordlöw wrote:

On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote:
The difference is that D is more verbose. Am I missing 
something? Can we have C's behaviour in D?


Something like

auto I(T)(T im)
if (isNumeric!T)
{
return complex(0, im);
}

unittest
{
auto x = 1 + 2.I;
}


Nice. But I am unsure of how to use this. I just pasted the 
definition of I inside the main function of my program followed 
by auto x = 1 + 2.I; and the compiler complained with Error: no 
property 'I' for type 'int'.


Try placing it outside the function. Method call syntax doesn't 
work with nested functions, see here:


https://dlang.org/spec/function.html#pseudo-member

"The reason why local symbols are not considered by UFCS, is to 
avoid unexpected name conflicts."


Re: what is mean? ( Offset 78887H Record Type 00C3)

2016-11-20 Thread xky via Digitalmars-d-learn

On Saturday, 19 November 2016 at 09:35:33 UTC, Basile B. wrote:

Is the message is about double definition ?


I knew the cause. You were right. It is my mistake.

I'm really sorry.


Re: shared arrray problem

2016-11-20 Thread ag0aep6g via Digitalmars-d-learn

On 11/20/2016 04:34 AM, Charles Hixson via Digitalmars-d-learn wrote:

Whether you would call the change "break things for your code" might be
dubious.  It would be effectively broken, even if technically my code
was doing the correct thing.  But my code wouldn't be storing the data
that needed storing, so effectively it would be broken.


I don't see how it's dubious. It's an error by the user. When users are 
given a dynamic array (and not by reference), they cannot expect that 
your code sees changes to length. That's just not how arrays work. When 
a user has that wrong expectation, and writes wrong code because of it, 
then it's arguably their own fault. However, if you want you can hold 
their hand a bit and make the mistake less likely.



"Write something
for yourself" is what I'd like to do, given that the language doesn't
have that built-in support, but I can't see how to do it.


Wrap the array in a struct that has indexing, but doesn't allow setting 
the length or appending. Here's a quick prototype:



struct ConstLengthArray(E)
{
private E[] data;
this(E[] arr) { this.data = arr; }
ref inout(E) opIndex(size_t i) inout { return data[i]; }
@property size_t length() const { return data.length; }
}

void main()
{
auto cla = ConstLengthArray!ubyte([1, 2, 3, 4, 5]);

/* Mutating elements is allowed: */
cla[0] = 10;
assert(cla[0] == 10);

/* No setting length, no appending: */
static assert(!__traits(compiles, cla.length = 3));
static assert(!__traits(compiles, cla ~= 6));
}


You might want to add support for slicing, concatenation, etc. Maybe 
allow implicit conversion to const(E[]), though that would also allow 
conversion to const(E)[] and that has a settable length again.


Re: How to declare function with the same call signature as another?

2016-11-20 Thread Nicholas Wilson via Digitalmars-d-learn

On Sunday, 20 November 2016 at 11:19:24 UTC, Tofu Ninja wrote:
I feel like this should be simple but I can't seem to figure it 
out. How do I declare a function to have the same call 
signature as another function/callable type?


Like if I have:

alias Sig = int function(int x, int y);

How do I define a function such that it will have the same call 
signature as Sig? How do I take into account all the extra 
stuff that can go into a function signature like the argument 
attributes and the return type attributes etc.?


Another way to phrase this question would be, how do I pass a 
function signature into a template and actually define 
functions with it?


Related question, if I have Sig, how would I define DeltaSig to 
be exactly the same as Sig but with an extra parameter at the 
start or end of the parameter list?


Thanks :)


Or if you want additional parameters.

ReturnType!Sig func(int paramBefore, Parameters!Sig args, int 
paramAfter) { ... }


Re: How to declare function with the same call signature as another?

2016-11-20 Thread Nicholas Wilson via Digitalmars-d-learn

On Sunday, 20 November 2016 at 11:19:24 UTC, Tofu Ninja wrote:
I feel like this should be simple but I can't seem to figure it 
out. How do I declare a function to have the same call 
signature as another function/callable type?


Like if I have:

alias Sig = int function(int x, int y);

How do I define a function such that it will have the same call 
signature as Sig? How do I take into account all the extra 
stuff that can go into a function signature like the argument 
attributes and the return type attributes etc.?


Another way to phrase this question would be, how do I pass a 
function signature into a template and actually define 
functions with it?


Related question, if I have Sig, how would I define DeltaSig to 
be exactly the same as Sig but with an extra parameter at the 
start or end of the parameter list?


Thanks :)

import std.traits;
ReturnType!Sig func(Parameters!Sig args)
{
//...
}


How to declare function with the same call signature as another?

2016-11-20 Thread Tofu Ninja via Digitalmars-d-learn
I feel like this should be simple but I can't seem to figure it 
out. How do I declare a function to have the same call signature 
as another function/callable type?


Like if I have:

alias Sig = int function(int x, int y);

How do I define a function such that it will have the same call 
signature as Sig? How do I take into account all the extra stuff 
that can go into a function signature like the argument 
attributes and the return type attributes etc.?


Another way to phrase this question would be, how do I pass a 
function signature into a template and actually define functions 
with it?


Related question, if I have Sig, how would I define DeltaSig to 
be exactly the same as Sig but with an extra parameter at the 
start or end of the parameter list?


Thanks :)




Re: Popular embedded language for scripting in D

2016-11-20 Thread Soulsbane via Digitalmars-d-learn

On Saturday, 19 November 2016 at 22:18:39 UTC, Sai wrote:
I have seen luad and Walters own JavaScript VM that can be used 
in D for embedded scripting purpose in an application.


I was wondering which is more popular among D applications? Any 
suggestions?


Thanks, sai


I've used LuaD in a couple projects now and been fairly happy 
with it. I'm partial to Lua though(not a fan of Javascript).