Re: Why double not? (!!)
On Saturday, 19 November 2016 at 07:51:36 UTC, Is it possible to
store different generic types? wrote:
On Saturday, 19 November 2016 at 06:58:38 UTC, Era Scarecrow
wrote:
On Saturday, 19 November 2016 at 04:54:22 UTC, Xinok wrote:
On Saturday, 19 November 2016 at 03:52:02 UTC, Ryan wrote:
Why do I see double `not` operators sometimes in D code? An
example it the last post of this thread.
http://forum.dlang.org/thread/ktlpnikvdwgbvfaam...@forum.dlang.org
import core.sys.windows.windows : GetConsoleCP;
bool hasConsole = !!GetConsoleCP();
Thanks.
It's a more concise way of writing:
GetConsoleCP() != 0
You can do this in C/C++ as well (and presumably some other
languages).
Hmmm... thinking about it, it does make perfect sense. The
first ! converts it to bool, the other inverts it back to it's
positive/negative state.
Although it's a combination of logic I wouldn't have through
of unless I saw it. But testing the result on any number
(float, double or real) won't be precise and would take far
longer (and more complicated) using another method.
It's a very common practice in any language that uses
truthy/falsey, especially seen a lot in Javascript.
Generally it's not necessary unless you want to be explicit
about checking upon a bool.
Ex.
auto hasModel = !!view.model;
if (hasModel) {
...
}
Could very well just be
auto model = view.model;
if (model) {
}
It's especially difficult with numbers like you did point out and
it completely depends on languages.
Most languages have false when it's 0, null, undefined etc. and
everything else is true.
Which means -1 would be true, 0 would be false, 1 would be true,
0.01 would be true, -0.1 would be true.
Re: what is mean? ( Offset 78887H Record Type 00C3)
On Saturday, 19 November 2016 at 07:12:49 UTC, Nicholas Wilson wrote: If you're using x64 then you should be using the microsoft linker. are you invoking the linker manually? I would guess that some files are old and compiled separately, and the source was changed at some point. But we don't have source or anything to compare against.
Re: what is mean? ( Offset 78887H Record Type 00C3)
On Saturday, 19 November 2016 at 07:12:49 UTC, Nicholas Wilson wrote: If you're using x64 then you should be using the microsoft linker. ok are you invoking the linker manually? no... So, I got msbuild.zip from another website and found link.exe. Can I replace this with "C:\D\dmd2\windows\bin\link.exe"? Please let me know more.
Re: what is mean? ( Offset 78887H Record Type 00C3)
On Saturday, 19 November 2016 at 08:29:08 UTC, Era Scarecrow wrote: On Saturday, 19 November 2016 at 07:12:49 UTC, Nicholas Wilson wrote: If you're using x64 then you should be using the microsoft linker. are you invoking the linker manually? I would guess that some files are old and compiled separately, and the source was changed at some point. But we don't have source or anything to compare against. In fact, we have been using DMDs for some time, and this has happened since we installed the new DMD.
Re: what is mean? ( Offset 78887H Record Type 00C3)
On Saturday, 19 November 2016 at 08:59:36 UTC, xky wrote: On Saturday, 19 November 2016 at 07:12:49 UTC, Nicholas Wilson wrote: If you're using x64 then you should be using the microsoft linker. ok are you invoking the linker manually? no... So, I got msbuild.zip from another website and found link.exe. Can I replace this with "C:\D\dmd2\windows\bin\link.exe"? Please let me know more. No, OPTLINK is the right linker for DMD32 (because of the object format, OMF), unless you use the -mscoff32 switch (which has for effect to produce another object format, that OPTLINK doesn't know to link). Your issue is likely not a linker issue. Is the message is about double definition ?
Complex numbers are harder to use than in C
Dear all,
I just discovered D and I am translating some numerical code I
wrote in C. I was surprised to learn that there are at least two
things that are easier in C than in D:
+ Writing complex numbers
C: complex double z = 2.0 + 3.0*I;
D: auto z = complex(2.0, 3.0);
+ Arrays of complex numbers
C: complex double a[2][2] = {{1.0*I, 0.0}, {0.0, 1.0*I}};
D: Complex!double[2][2] a = [[complex(0.0, 1.0), complex(0.0)],
[complex(0.0), complex(0.0, 1.0)]];
The difference is that D is more verbose. Am I missing something?
Can we have C's behaviour in D?
Using mixin in array declarations
In C one can do the following:
# define N 10
double M[N][N];
In D I would like to achieve the same result. I tried with:
mixin("int N = 10;");
double[N][N] M;
but the compiler (DMD) complained with Error: variable N cannot
be read at compile time.
What am I doing wrong?
Re: what is mean? ( Offset 78887H Record Type 00C3)
On Saturday, 19 November 2016 at 09:35:33 UTC, Basile B. wrote:
No, OPTLINK is the right linker for DMD32 (because of the
object format, OMF), unless you use the -mscoff32 switch (which
has for effect to produce another object format, that OPTLINK
doesn't know to link). Your issue is likely not a linker issue.
Is the message is about double definition ?
I do not think so.
When i using dmd for directly("dmd code.d"), get this message.
and using with dub, get here message:
Linking...
Can't run '\bin\link.exe', check PATH
dmd failed with exit code -1.
I think I made a mistake, but I do not know what it is...
Re: Using mixin in array declarations
On 19/11/2016 10:46 PM, Marduk wrote:
In C one can do the following:
# define N 10
double M[N][N];
In D I would like to achieve the same result. I tried with:
mixin("int N = 10;");
double[N][N] M;
but the compiler (DMD) complained with Error: variable N cannot be read
at compile time.
What am I doing wrong?
enum N = 10;
double[N][N] M;
enum is a constant available for use at compile time, your int there is
a runtime variable not accessible at runtime.
Missing features from numpy
In order to make D more useful for writing numerical code I would like to suggest the following extensions for built-in functions: 1. Generate random arrays 2. Arithmetic operations with arrays 3. Mathematical functions evaluated element-wise for arrays I am aware of the existence of mir-glas, which will eventually satisfy 2. As for 1. and 3. I guess it is just a matter of method overloading. Eventually, it would be great to have a Rosetta stone to help newcomers start using D for numerical computations.
Re: Using mixin in array declarations
On Saturday, 19 November 2016 at 09:49:48 UTC, rikki cattermole
wrote:
On 19/11/2016 10:46 PM, Marduk wrote:
In C one can do the following:
# define N 10
double M[N][N];
In D I would like to achieve the same result. I tried with:
mixin("int N = 10;");
double[N][N] M;
but the compiler (DMD) complained with Error: variable N
cannot be read
at compile time.
What am I doing wrong?
enum N = 10;
double[N][N] M;
enum is a constant available for use at compile time, your int
there is a runtime variable not accessible at runtime.
Great! Thanks! I just understood why what I did did not work.
Array operations with multidimensional arrays
In the documentation one can learn how to do array operations with 1D arrays. However, this does not scale up for 2D arrays. For example, the following does not work: int[2][2] a,b; a = [[1,1],[1,1]]; b[][] = a[][]*2; Additionally, I would like to assign 2D sub-arrays of a 3D array, i.e. something like the following: int[3][2][2] a; a[0] = [[2,2], [2,2]]; I did not understand how to use std.experimental.ndslice to do this. An example would be greatly appreciated.
Re: Complex numbers are harder to use than in C
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;
}
Re: Complex numbers are harder to use than in C
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;
How to enable SIMD instructions in core.simd
Found that I was not able to use SIMD as
import core.simd : __simd;
produces the error: 'module core.simd import '__simd' not found'.
Upon further inspection I found that the D_SIMD version is not
defined as
version (D_SIMD)
{
pragma(msg, "SIMD Support");
}
else
{
pragma(msg, "No SIMD Support");
}
prints 'No SIMD Support' at compile time. In the docs for SIMD
[1] I can see the line 'Depending on the architecture, compiler
flags may be required to activate support for SIMD types.', but
no information on which architectures and more importantly what
the compiler flags are.
My architecture is Intel x86_64 and I am using dub with latest
ldmd. How would I enable SIMD instructions in a simple way? (I
have another issue with dub & compiler arguments also but I can
create another thread if that continues to bother me)
Thanks in advance.
[1] https://dlang.org/spec/simd.html
Re: How to enable SIMD instructions in core.simd
On Saturday, 19 November 2016 at 13:11:18 UTC, e-y-e wrote: ... Sorry for the noise, I found an LDC issue [1] that explains where I am going wrong (in short, core.simd is not supported in LDC, instead ldc.simd should be used). [1] https://github.com/ldc-developers/ldc/issues/595
Re: Using mixin in array declarations
On Saturday, November 19, 2016 09:46:08 Marduk via Digitalmars-d-learn
wrote:
> In C one can do the following:
>
> # define N 10
>
> double M[N][N];
>
>
> In D I would like to achieve the same result. I tried with:
>
> mixin("int N = 10;");
>
> double[N][N] M;
>
>
> but the compiler (DMD) complained with Error: variable N cannot
> be read at compile time.
>
> What am I doing wrong?
A string mixin literally puts the code there. So, doing
mixin("int n = 10");
double[n][n] m;
is identical to
int n = 10;
double[n][n] m;
except that you made the compile do the extra work of converting the string
mixin to the code. String mixins really only become valuable when you start
doing string manipulation rather than simply using string literals. If you
want a compile-time constant, then use the enum keyword. e.g.
enum n = 10;
double[n][n] m;
And if you want the value of n to be calculated instead of being fixed, then
you can even do something like
enum n = calcN();
double[n][n] m;
so long as calcN can be run at compile time.
- Jonathan M Davis
Re: Why double not? (!!)
It's a more concise way of writing: GetConsoleCP() != 0 You can do this in C/C++ as well (and presumably some other languages). Hmmm... thinking about it, it does make perfect sense. The first ! converts it to bool, the other inverts it back to it's positive/negative state. Wouldn't this just be the same as auto hasConsole = cast(bool) GetConsoleCP(); ? I think the GetConsoleCP() != 0 code is the clearest about your intentions.
Re: Why double not? (!!)
On Saturday, 19 November 2016 at 15:40:38 UTC, Ryan wrote: Wouldn't this just be the same as auto hasConsole = cast(bool) GetConsoleCP(); ? Yes, it is in D, though the habit often comes from C where things are different. But people also may prefer !! for just being shorter and once you know the pattern, you'll see them as meaning the same thing. I think the GetConsoleCP() != 0 code is the clearest about your intentions. yeah that's my preference too. But they still mean the same thing so you get used to all the forms.
Re: Why double not? (!!)
On Saturday, 19 November 2016 at 15:50:26 UTC, Adam D. Ruppe wrote: On Saturday, 19 November 2016 at 15:40:38 UTC, Ryan wrote: Wouldn't this just be the same as auto hasConsole = cast(bool) GetConsoleCP(); ? Yes, it is in D, though the habit often comes from C where things are different. But people also may prefer !! for just being shorter and once you know the pattern, you'll see them as meaning the same thing. Yes it is a C idiom to coerce the boolean value to be 0 or 1. Since C99 C has the built in type bool which will also coerce the value. bool hasConsole = (bool)GetConsoleCP(); will do. If the code is to be compiled on a pre C99 compiler then it is problematic as the value depend on the definition of the type bool. In that case you have to use the !! or the !=0 idiom. That's why C code still often use them because of the risk of being compiled on an old compiler (and Microsoft doesn't implement C99 anyway in MSVC, so for real portable code it's kind of required).
Re: Complex numbers are harder to use than in C
On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote:
Dear all,
I just discovered D and I am translating some numerical code I
wrote in C. I was surprised to learn that there are at least
two things that are easier in C than in D:
+ Writing complex numbers
C: complex double z = 2.0 + 3.0*I;
D: auto z = complex(2.0, 3.0);
+ Arrays of complex numbers
C: complex double a[2][2] = {{1.0*I, 0.0}, {0.0, 1.0*I}};
D: Complex!double[2][2] a = [[complex(0.0, 1.0), complex(0.0)],
[complex(0.0), complex(0.0, 1.0)]];
The difference is that D is more verbose. Am I missing
something? Can we have C's behaviour in D?
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]];
Re: the best language I have ever met(?)
On Friday, 18 November 2016 at 21:28:44 UTC, ketmar wrote:
On Friday, 18 November 2016 at 20:31:57 UTC, Igor Shirkalin
wrote:
After 2 hours of brain breaking (as D newbie) I have come to:
uint_array.map!(v=>"%x".format(v)).join(", ")
Why 2 hours? Because I have started with 'joiner' function and
aftewords found out the 'join'.
To my mind there is more simple form for this task in D (about
formatting).
sure ;-)
import std.stdio;
import std.format;
void main () {
uint[$] a = [42, 69];
string s = "%(%s, %)".format(a);
writefln(s);
}
Accepted.
Is it really needed to call 'writefln'? I mean 'f'.
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote:
import std.stdio;
import std.format;
void main () {
uint[$] a = [42, 69];
string s = "%(%s, %)".format(a);
writefln(s);
}
Please don't post non-d.
People might use it an then complain that it does not work.
Let these people to complain. ;)
How to correct share data between threads?
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(&pp.processingData);
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.
Re: Array operations with multidimensional arrays
On Saturday, 19 November 2016 at 10:20:16 UTC, Marduk wrote: Additionally, I would like to assign 2D sub-arrays of a 3D array, i.e. something like the following: int[3][2][2] a; a[0] = [[2,2], [2,2]]; You have the dimensions the wrong way around. a is a 2 element array of 2 element arrays of 3 element arrays. int[3][2][2] a; a[0] = [[2,2,2], [2,2,2]]; works fine.
shared arrray problem
I have a piece of code that looks thus:
/**Returns an editable file header missing the header length and data
* length portions. Those cannot be edited by a routine outside this
class.
* Access to them is available via the lenHead and lenRec functions.
* Warning: Do NOT change the size of the header. If you do the size
* will be reset to the current value before it is saved, and results are
* unpredictable. Also do not replace it. This class maintains it's own
* pointer to the header, and your replacement will be ignored. */
ubyte[]header()@property{return fHead[4..$];}
I want other classes to be able to modify the tail of the array, but not
to resize it. Eventually it should be written to a file. This way works
(well, should work) but looks radically unsafe for the reasons indicated
in the comments. I'm sure there must be a better way, but can't think
of what it would be. The only alternative I've been able to think of
is, approx:
boolsaveToHeader (ubyte[] rec){ ... buf[4..$] = rec[0..$]; ... }
but that would be guaranteed to have an extra copying step, and it's
bool because if the length of the passed parameter isn't correct
saveToHeader would fail. It may still be better since in this case the
copying would be rather minimal, but the general problem bothers me
because I don't see a good solution.
Re: How to correct share data between threads?
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(&pp.processingData);
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.
Re: shared arrray problem
On Saturday, 19 November 2016 at 18:51:05 UTC, Charles Hixson
wrote:
ubyte[]header()@property{return
fHead[4..$];}
This method should do what you want. You are only returning a
slice of the fHead array, so if the caller modifies the length it
will only affect of the return value, and not the length of fHead
itself.
Re: Array operations with multidimensional arrays
On Saturday, 19 November 2016 at 17:37:58 UTC, John Colvin wrote: On Saturday, 19 November 2016 at 10:20:16 UTC, Marduk wrote: Additionally, I would like to assign 2D sub-arrays of a 3D array, i.e. something like the following: int[3][2][2] a; a[0] = [[2,2], [2,2]]; You have the dimensions the wrong way around. a is a 2 element array of 2 element arrays of 3 element arrays. int[3][2][2] a; a[0] = [[2,2,2], [2,2,2]]; works fine. Thanks a lot! Now I get what it means that array declarations are read from right to left.
Re: Complex numbers are harder to use than in C
On Saturday, 19 November 2016 at 16:17:08 UTC, Meta wrote:
On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote:
Dear all,
I just discovered D and I am translating some numerical code I
wrote in C. I was surprised to learn that there are at least
two things that are easier in C than in D:
+ Writing complex numbers
C: complex double z = 2.0 + 3.0*I;
D: auto z = complex(2.0, 3.0);
+ Arrays of complex numbers
C: complex double a[2][2] = {{1.0*I, 0.0}, {0.0, 1.0*I}};
D: Complex!double[2][2] a = [[complex(0.0, 1.0),
complex(0.0)], [complex(0.0), complex(0.0, 1.0)]];
The difference is that D is more verbose. Am I missing
something? Can we have C's behaviour in D?
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.
Re: Using mixin in array declarations
On Saturday, 19 November 2016 at 13:57:26 UTC, Jonathan M Davis
wrote:
On Saturday, November 19, 2016 09:46:08 Marduk via
Digitalmars-d-learn wrote:
[...]
A string mixin literally puts the code there. So, doing
mixin("int n = 10");
double[n][n] m;
is identical to
int n = 10;
double[n][n] m;
except that you made the compile do the extra work of
converting the string mixin to the code. String mixins really
only become valuable when you start doing string manipulation
rather than simply using string literals. If you want a
compile-time constant, then use the enum keyword. e.g.
enum n = 10;
double[n][n] m;
And if you want the value of n to be calculated instead of
being fixed, then you can even do something like
enum n = calcN();
double[n][n] m;
so long as calcN can be run at compile time.
- Jonathan M Davis
Thank you very much for taking the time to write such a detailed
explanation. The first part I had already figured out.
String mixins really only become valuable when you start doing
string manipulation rather than simply using string literals.
Yes. I saw some examples in the docs.
The last part is very interesting.
Re: Complex numbers are harder to use than in C
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'.
Re: Complex numbers are harder to use than in C
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).
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 17:12:13 UTC, Igor Shirkalin
wrote:
string s = "%(%s, %)".format(a);
writefln(s);
}
Accepted.
Is it really needed to call 'writefln'? I mean 'f'.
no. it's a leftover from the code without format. it originally
was `writefln("%(%s, %)", a);`, but i wanted to show `format`
function too, and forgot to remove `f`. actually, it is a BUG to
call `writefln` here, 'cause who knows, `s` may contain '%', and
then boom! all hell broke loose. ;-)
Re: Array operations with multidimensional arrays
On Saturday, 19 November 2016 at 19:36:50 UTC, Marduk wrote: On Saturday, 19 November 2016 at 17:37:58 UTC, John Colvin wrote: On Saturday, 19 November 2016 at 10:20:16 UTC, Marduk wrote: Additionally, I would like to assign 2D sub-arrays of a 3D array, i.e. something like the following: int[3][2][2] a; a[0] = [[2,2], [2,2]]; You have the dimensions the wrong way around. a is a 2 element array of 2 element arrays of 3 element arrays. int[3][2][2] a; a[0] = [[2,2,2], [2,2,2]]; works fine. Thanks a lot! Now I get what it means that array declarations are read from right to left. The way I think about it is this: int is a type. int[3] is an array of 3 ints. Similarly, int[3] is a type, so an array of 2 int[3]s is int[3][2] and so on...
Re: fPIC Error
On 11/18/2016 10:35 PM, deadalnix via Digitalmars-d-learn wrote: On Thursday, 3 November 2016 at 06:11:48 UTC, rikki cattermole wrote: [Environment32] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so [Environment64] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so I'm sorry bit that's horseshit. I'm not compiling everything with fPIC because DMD can't get it's act straight. IIRC, LDC didn't have that problem. I don't remember testing gdc. But, yes, it is quite annoying.
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 20:54:32 UTC, ketmar wrote:
On Saturday, 19 November 2016 at 17:12:13 UTC, Igor Shirkalin
wrote:
string s = "%(%s, %)".format(a);
writefln(s);
}
Accepted.
Is it really needed to call 'writefln'? I mean 'f'.
no. it's a leftover from the code without format. it originally
was `writefln("%(%s, %)", a);`, but i wanted to show `format`
function too, and forgot to remove `f`. actually, it is a BUG
to call `writefln` here, 'cause who knows, `s` may contain '%',
and then boom! all hell broke loose. ;-)
Got it! Thanks.
Re: shared arrray problem
On 11/19/2016 11:10 AM, Nicolas Gurrola via Digitalmars-d-learn wrote:
On Saturday, 19 November 2016 at 18:51:05 UTC, Charles Hixson wrote:
ubyte[]header()@property {return fHead[4..$];}
This method should do what you want. You are only returning a slice of
the fHead array, so if the caller modifies the length it will only
affect of the return value, and not the length of fHead itself.
It's worse than that, if they modify the length the array may be
reallocated in RAM so that the pointers held by the containing class do
not point to the changed values. (Read the header comments...it's not
nice at all.)
More, the class explicitly requires the array to be a particular length
as it needs to fit into a spot in a binary file, so I really want to
forbid any replacement of the array for any reason. The first four
bytes are managed by the class and returned via alternate routines which
do not allow the original values to be altered, and this is necessary.
I could make them immutable, but actually what I do is return, e.g., an
int of 256 * fHead[0] + fHead[1], which is the length of the header.
It's an int to allow negative values to be returned in case of error.
So what I'll probably eventually decide on is some variation of
saveToHead, e.g.:
boolsaveToHeader(ubyte[] rec)
{ if(rec.length + 4 > dheader)returnfalse;
fHead[4..recLen + 4] = rec[0..$];
returntrue;
}
unless I can think of something better. Actually for this particular
case that's not a bad approach, but for the larger problem it's a lousy
kludge.
Re: shared arrray problem
On 11/19/2016 10:26 PM, Charles Hixson via Digitalmars-d-learn wrote: It's worse than that, if they modify the length the array may be reallocated in RAM so that the pointers held by the containing class do not point to the changed values. (Read the header comments...it's not nice at all.) Arguably, any D programmer must be aware that appending to a dynamic array potentially means making a copy of the data, and that changes to length are not visible to other views of the data. But it's an opportunity to mess up, for sure. You could return a wrapper around the array that supports editing the data but not changing the length or appending. Looks like std.experimental.typecons.Final [1] is supposed to be that wrapper. But in a little test I can still set the length. Not sure if that's a bug, or if Final has slightly different goals. [1] https://dlang.org/phobos/std_experimental_typecons.html#.Final
Popular embedded language for scripting in D
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
Re: shared arrray problem
On 11/19/2016 01:50 PM, ag0aep6g via Digitalmars-d-learn wrote: On 11/19/2016 10:26 PM, Charles Hixson via Digitalmars-d-learn wrote: It's worse than that, if they modify the length the array may be reallocated in RAM so that the pointers held by the containing class do not point to the changed values. (Read the header comments...it's not nice at all.) Arguably, any D programmer must be aware that appending to a dynamic array potentially means making a copy of the data, and that changes to length are not visible to other views of the data. But it's an opportunity to mess up, for sure. You could return a wrapper around the array that supports editing the data but not changing the length or appending. Looks like std.experimental.typecons.Final [1] is supposed to be that wrapper. But in a little test I can still set the length. Not sure if that's a bug, or if Final has slightly different goals. [1] https://dlang.org/phobos/std_experimental_typecons.html#.Final Yes. I was hoping someone would pop up with some syntax making the array, but not its contents, const or immutable, which I couldn't figure out how to do, and which is what I really hoped would be the answer, but it appears that this isn't part of the syntax. If the array is constant, so is it's contents. I really *can't* allow the length to be changed, and if the array is reallocated, it won't get saved. But the contents of the array are intended to be changed by the calling routines. Again, for this particular problem the kludge of copying the values into the array works fine (and is what I've decided to do), but that's not a good general solution to this kind of problem.
Re: Compiling and linking libraries
On Wednesday, 16 November 2016 at 16:05:06 UTC, Mike Parker wrote: On Wednesday, 16 November 2016 at 14:59:40 UTC, Edwin van Leeuwen wrote: Thank you for this! Great information. So dub dynamically "add" code from the dll into the source code at runtime? Also will I ever need to learn how to use static libraries and is there a reason to?
Re: fPIC Error
On Saturday, 19 November 2016 at 21:14:47 UTC, Charles Hixson wrote: [...] IIRC, LDC didn't have that problem. I don't remember testing gdc. But, yes, it is quite annoying. That's because we can maintain those compilers with the distribution and configure them appropriately to compile with hardening flags and integrate properly with the distro. GDC is an issue here, since AFAIK it doesn't support PIC yet, so for GDC - if it works - there will be some kind of workaround in place (telling the linker to not assume PIC code, I guess). DMD has issues because it's a 3rd-party product - ideally, the compiler should be adjusted to output PIC code by default. You can find more information on this change at https://wiki.debian.org/Hardening/PIEByDefaultTransition
Re: shared arrray problem
On 11/20/2016 01:33 AM, Charles Hixson via Digitalmars-d-learn wrote: Yes. I was hoping someone would pop up with some syntax making the array, but not its contents, const or immutable, which I couldn't figure out how to do, and which is what I really hoped would be the answer, but it appears that this isn't part of the syntax. Yup, head const is not part of the language. You'd have to find a library solution or write something yourself. I really *can't* allow the length to be changed, Your emphasis suggests that user could break things for your code. They can't. Any changes to the length will only affect the slice on the user's end. They can only fool themselves. That may be bad enough to warrant a more restricted return type, but for your code it's safe to return a plain dynamic array.
Re: Array operations with multidimensional arrays
On Saturday, 19 November 2016 at 21:05:49 UTC, John Colvin wrote: On Saturday, 19 November 2016 at 19:36:50 UTC, Marduk wrote: Thanks a lot! Now I get what it means that array declarations are read from right to left. The way I think about it is this: int is a type. int[3] is an array of 3 ints. Similarly, int[3] is a type, so an array of 2 int[3]s is int[3][2] and so on... A while back I was writing a Sudoku solver which used static array types. It went something like this: alias Possible = byte[10]; //1-9 possible, plus final known value alias Block = Possible[9]; alias Sudoku = Block[9]; Actual Sudoku: byte[10][9][9] While this breaks down easily enough, if the order had been the other way around it wouldn't have been extensible this way to making larger structures from basic types/arrays.
Re: shared arrray problem
On 11/19/2016 05:52 PM, ag0aep6g via Digitalmars-d-learn wrote: On 11/20/2016 01:33 AM, Charles Hixson via Digitalmars-d-learn wrote: Yes. I was hoping someone would pop up with some syntax making the array, but not its contents, const or immutable, which I couldn't figure out how to do, and which is what I really hoped would be the answer, but it appears that this isn't part of the syntax. Yup, head const is not part of the language. You'd have to find a library solution or write something yourself. I really *can't* allow the length to be changed, Your emphasis suggests that user could break things for your code. They can't. Any changes to the length will only affect the slice on the user's end. They can only fool themselves. That may be bad enough to warrant a more restricted return type, but for your code it's safe to return a plain dynamic array. 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. "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. I want to end up with a continuous array of ubytes of a given length with certain parts reserved to only be directly accessible to the defining class, and other parts accessible to the calling class(es). And the length of the array isn't known until run time. So I guess the only safe solution is to do an extra copy...which isn't a problem in this particular application as I only need to do it twice per file opening (once on opening, once on closing), but for other applications would be a real drag.
Re: Popular embedded language for scripting in D
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 Look at one more option. https://forum.dlang.org/thread/trxrewjxncocihftj...@forum.dlang.org It is built already in GUI QtE5 (Qt-5) and has big documentation of Qt
Re: fPIC Error
On Thursday, 3 November 2016 at 05:16:11 UTC, Dlang User wrote:
I am running Debian Testing and I think I have run into the
recent fPIC issue. This is the source code for the test
project I am using:
import std.stdio;
void main()
{
writeln("Edit source/app.d to start your project.");
readln();
}
When I try to compile a project, I get the following errors
(truncated for brevity):
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libphobos2.a(thread_26c_155.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on
output
collect2: error: ld returned 1 exit status
dmd failed with exit code 1.
Exit code 2
Build complete -- 1 error, 0 warnings
I got the same problem, still under Debian. A fix is to use these
flags:
dmd -shared -m64 -fPIC -defaultlib=libphobos2.so app.d
You can also use another compiler:
dub --compiler=ldc2
or
rdmd --compiler=ldc2
Note that it is not recommended to use gdc because it is not up
to date, use dmd or ldc2.
Also note, that if you use Emacs + Org Mode,
http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.html
you will encounter the same problem. A fix is to add the
following line in your .emacs file:
(setq org-babel-D-compiler "rdmd --compiler=ldc2")
Vincent
