Re: windows wininet library
http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/lib/lib32/wininet.def ?
Re: strlen, strcpy, etc errors when trying to link an object
On Monday, 2 February 2015 at 05:30:04 UTC, ketmar wrote: On Sun, 01 Feb 2015 18:34:01 +, irtcupc wrote: did you build BeaEngine with dmc? if not, try to rebuild with dmc compiler. It has worked, compiled with dmc, __IBMCPP__ compatibility mode, thx for pointing me out the idea.
Re: Conway's game of life
It's true that I have to change that function. Thanks for the notice! Why do you think that D's GC is crap? On Sunday, 1 February 2015 at 21:54:43 UTC, Foo wrote: On Sunday, 1 February 2015 at 21:00:07 UTC, gedaiu wrote: Hi, I implemented Conway's game of life in D. What do you think that I can improve to this program to take advantage of more D features? https://github.com/gedaiu/Game-Of-Life-D Thanks, Bogdan For each remove you create a new array. That is lavish. You should use a bool inside the struct Cell. If it's false, the cell is not displayed and is out of the game. My suggestion: don't use the D GC, it's crap. Try to circumvent the GC wherever possible. Therefore you should use the -vgc compiler flag and the @nogc attribute.
Re: Conway's game of life
I don't think that the line of code is wrong. If use && the
function will check for neighbours only on diagonals. Having ||
allows the search on the vertical and horizontal axis and
diagonals.
There are some tests that check the function:
unittest {
CellList world = [ Cell(0,0), Cell(0,1), Cell(0,2), Cell(1,0),
Cell(1,2), Cell(2,0), Cell(2,1), Cell(2,2) ];
assertEqual(Cell(1,1).neighbours(world), world.length);
}
unittest {
CellList world = [ Cell(0,0), Cell(1,1), Cell(2,2), Cell(3,3) ];
assertEqual(Cell(1,1).neighbours(world), 2);
}
I don't see a glitch.
Thanks,
Bogdan
On Sunday, 1 February 2015 at 22:51:42 UTC, FG wrote:
On 2015-02-01 at 22:00, gedaiu wrote:
I implemented Conway's game of life in D.
I think you are playing a different game here.
/// Count cell neighbours
long neighbours(Cell myCell, CellList list) {
long cnt;
foreach(cell; list) {
auto diff1 = abs(myCell.x - cell.x);
auto diff2 = abs(myCell.y - cell.y);
if(diff1 == 1 || diff2 == 1) cnt++; // Why ||
instead of && ???
}
return cnt;
}
Re: Conway's game of life
On 2015-02-02 at 12:23, FG wrote: Cell(0,3) is not a neighbour bit fits the (diff1 == 1 || diff2 == 1) criterion. s/bit/but/
Re: Conway's game of life
Bloody Thunderbird has sent a reply to the OP and not to the NG.
On 2015-02-02 at 11:45, gedaiu wrote:
I don't think that the line of code is wrong. If use && the function will check
for neighbours only on diagonals. Having || allows the search on the vertical and
horizontal axis and diagonals.
In short: Yes, && alone would check only diagonals, but I forgot to tell you to
also change the ==.
(diff1 == 1 || diff2 == 1) -- bad, accepts whole neighbouring rows and columns
(diff1 == 1 && diff2 == 1) -- bad, accepts only neighbouring diagonals
(diff1 <= 1 && diff2 <= 1) -- correct, I think :)
This unittest should show the difference:
unittest {
CellList world = [ Cell(0,0), Cell(0,1), Cell(0,2), Cell(0,3) ];
assertEqual(Cell(1,1).neighbours(world), 3);
}
Cell(0,3) is not a neighbour bit fits the (diff1 == 1 || diff2 == 1) criterion.
cast a C char array - offset ?
The manual section about interfacing from c states that "type[]"
is inter-compatible from C to D,
however, I face this strange case:
- C declaration:
char identifier[64];
- D declaration:
char[64] identifier;
- the result is only correct if i slice by (- pointer size):
char[64] fromC(char[64] * thing)
{
const offs = size_t.sizeof;
return thing[-offs.sizeof .. $-offs];
}
Is this correct ?
Re: Conway's game of life
Uf... you are right!
I've fixed it.
Thanks!
On Monday, 2 February 2015 at 11:23:17 UTC, FG wrote:
Bloody Thunderbird has sent a reply to the OP and not to the NG.
On 2015-02-02 at 11:45, gedaiu wrote:
I don't think that the line of code is wrong. If use && the
function will check for neighbours only on diagonals. Having
|| allows the search on the vertical and horizontal axis and
diagonals.
In short: Yes, && alone would check only diagonals, but I
forgot to tell you to also change the ==.
(diff1 == 1 || diff2 == 1) -- bad, accepts whole neighbouring
rows and columns
(diff1 == 1 && diff2 == 1) -- bad, accepts only neighbouring
diagonals
(diff1 <= 1 && diff2 <= 1) -- correct, I think :)
This unittest should show the difference:
unittest {
CellList world = [ Cell(0,0), Cell(0,1), Cell(0,2),
Cell(0,3) ];
assertEqual(Cell(1,1).neighbours(world), 3);
}
Cell(0,3) is not a neighbour bit fits the (diff1 == 1 || diff2
== 1) criterion.
Re: cast a C char array - offset ?
On 2015-02-02 at 13:16, irtcupc wrote:
The manual section about interfacing from c states that "type[]" is
inter-compatible from C to D,
however, I face this strange case:
- C declaration:
char identifier[64];
- D declaration:
char[64] identifier;
- the result is only correct if i slice by (- pointer size):
char[64] fromC(char[64] * thing)
{
const offs = size_t.sizeof;
return thing[-offs.sizeof .. $-offs];
}
Is this correct ?
So you have to shift the whole array right by 4 or 8 bytes? Strange.
Looks like an alignment issue. Is identifier part of a bigger structure?
Re: cast a C char array - offset ?
On 2/2/2015 9:16 PM, irtcupc wrote:
The manual section about interfacing from c states that "type[]" is
inter-compatible from C to D,
however, I face this strange case:
- C declaration:
char identifier[64];
- D declaration:
char[64] identifier;
- the result is only correct if i slice by (- pointer size):
char[64] fromC(char[64] * thing)
{
const offs = size_t.sizeof;
return thing[-offs.sizeof .. $-offs];
}
Is this correct ?
That's looking pretty wonky. You're slicing a pointer to a fixed-size
array. Why have you declared the parameter as a pointer? What problem
are you trying to solve? It would help a bit to see the declaration of
the C function that's giving you the array.
Re: cast a C char array - offset ?
On Monday, 2 February 2015 at 12:42:24 UTC, FG wrote:
On 2015-02-02 at 13:16, irtcupc wrote:
The manual section about interfacing from c states that
"type[]" is inter-compatible from C to D,
however, I face this strange case:
- C declaration:
char identifier[64];
- D declaration:
char[64] identifier;
- the result is only correct if i slice by (- pointer size):
char[64] fromC(char[64] * thing)
{
const offs = size_t.sizeof;
return thing[-offs.sizeof .. $-offs];
}
Is this correct ?
So you have to shift the whole array right by 4 or 8 bytes?
Strange.
Looks like an alignment issue. Is identifier part of a bigger
structure?
Yes:
C struct:
#pragma pack(1)
typedef struct _Disasm {
UIntPtr EIP;
UInt64 VirtualAddr;
UInt32 SecurityBlock;
char CompleteInstr[INSTRUCT_LENGTH];
UInt32 Archi;
UInt64 Options;
INSTRTYPE Instruction;
ARGTYPE Argument1;
ARGTYPE Argument2;
ARGTYPE Argument3;
PREFIXINFO Prefix;
InternalDatas Reserved_;
} DISASM, *PDISASM, *LPDISASM;
#pragma pack()
D struct:
align(1)
struct _Disasm {
void * EIP;
ulong VirtualAddr;
uint SecurityBlock;
char [INSTRUCT_LENGTH] CompleteInstr;
uint Archi;
ulong Options;
INSTRTYPE Instruction;
ARGTYPE Argument1;
ARGTYPE Argument2;
ARGTYPE Argument3;
PREFIXINFO Prefix;
uint Reserved_[40];
}
my current understanding is that:
- C: char CompleteInstr[INSTRUCT_LENGTH] is actually a raw chunk
- D: defining the member as char[INSTRUCT_LENGTH] is an error
- the first member of a D array is the .length
- first char actually stands where .length uses to be, which
explains the shift.
- I cant use fromStringz because it's not a null terminated string
Re: cast a C char array - offset ?
On Mon, 02 Feb 2015 13:23:23 +, irtcupc wrote:
> my current understanding is that:
> - C: char CompleteInstr[INSTRUCT_LENGTH] is actually a raw chunk - D:
> defining the member as char[INSTRUCT_LENGTH] is an error - the first
> member of a D array is the .length - first char actually stands where
> .length uses to be, which explains the shift.
nope. fixed length arrays doesn't have dedicated `.length` member. try
this:
align(1)
struct _Disasm {
align(1):
...
signature.asc
Description: PGP signature
Re: cast a C char array - offset ?
On Mon, 02 Feb 2015 13:32:57 +, ketmar wrote:
> On Mon, 02 Feb 2015 13:23:23 +, irtcupc wrote:
>
>> my current understanding is that:
>> - C: char CompleteInstr[INSTRUCT_LENGTH] is actually a raw chunk - D:
>> defining the member as char[INSTRUCT_LENGTH] is an error - the first
>> member of a D array is the .length - first char actually stands where
>> .length uses to be, which explains the shift.
>
> nope. fixed length arrays doesn't have dedicated `.length` member. try
> this:
>
> align(1)
> struct _Disasm {
> align(1):
> ...
actually, first align is not necessary at all. i.e.:
struct _Disasm {
align(1):
the difference is that `align` before struct tells how structure should
be packed (i.e. when you have `_Disasm[2] arr`). and `align` *inside*
struct tells compiler how struct *members* should be packed.
signature.asc
Description: PGP signature
Re: cast a C char array - offset ?
On Monday, 2 February 2015 at 12:57:37 UTC, Mike Parker wrote:
On 2/2/2015 9:16 PM, irtcupc wrote:
The manual section about interfacing from c states that
"type[]" is
inter-compatible from C to D,
however, I face this strange case:
- C declaration:
char identifier[64];
- D declaration:
char[64] identifier;
- the result is only correct if i slice by (- pointer size):
char[64] fromC(char[64] * thing)
{
const offs = size_t.sizeof;
return thing[-offs.sizeof .. $-offs];
}
Is this correct ?
That's looking pretty wonky. You're slicing a pointer to a
fixed-size array. Why have you declared the parameter as a
pointer? What problem are you trying to solve? It would help a
bit to see the declaration of the C function that's giving you
the array.
It looks like it's here:
https://code.google.com/p/beaengine/source/browse/trunk/beaengineSources/Includes/Routines_Disasm.c#763
However i haven't spent the time to dive in there since i'm not a
C guy at all.
Re: cast a C char array - offset ?
On Monday, 2 February 2015 at 13:34:28 UTC, ketmar wrote:
On Mon, 02 Feb 2015 13:32:57 +, ketmar wrote:
On Mon, 02 Feb 2015 13:23:23 +, irtcupc wrote:
my current understanding is that:
- C: char CompleteInstr[INSTRUCT_LENGTH] is actually a raw
chunk - D:
defining the member as char[INSTRUCT_LENGTH] is an error -
the first
member of a D array is the .length - first char actually
stands where
.length uses to be, which explains the shift.
nope. fixed length arrays doesn't have dedicated `.length`
member. try
this:
align(1)
struct _Disasm {
align(1):
...
actually, first align is not necessary at all. i.e.:
struct _Disasm {
align(1):
the difference is that `align` before struct tells how
structure should
be packed (i.e. when you have `_Disasm[2] arr`). and `align`
*inside*
struct tells compiler how struct *members* should be packed.
Thx, problem fixed, it works now.
Re: Time from timestamp?
On 1/31/15 1:07 AM, Jonathan M Davis via Digitalmars-d-learn wrote: On Friday, January 30, 2015 22:03:02 Jonathan M Davis via Digitalmars-d-learn wrote: Yeah. I really should add a unixTimeToSysTime function, Actually, maybe it should be a static function on SysTime called fromUnixTime to go with toUnixTime. I don't know. Regardless, it's a nicety that should be there, and I botched things by not having it. Might I suggest that you simply define an enum for UnixEpoch that's a SysTime. Then you can do whatever you want. Note that unixTimeToSysTime doesn't help the OP, his timestamp is in milliseconds since 1/1/1970. -Steve
Re: cast a C char array - offset ?
On 2015-02-02 at 14:40, irtcupc wrote:
On Monday, 2 February 2015 at 13:34:28 UTC, ketmar wrote:
struct _Disasm {
align(1):
the difference is that `align` before struct tells how structure should
be packed (i.e. when you have `_Disasm[2] arr`). and `align` *inside*
struct tells compiler how struct *members* should be packed.
Thx, problem fixed, it works now.
Yeah, without the align(1) inside the struct, the members of the struct were
not crammed, so VirtualAddr started in byte x+8 instead of x+4 (on a 32-bit
machine), and that was the source of the extra 4-byte shift you encountered.
Re: Time from timestamp?
On Monday, February 02, 2015 08:49:58 Steven Schveighoffer via Digitalmars-d-learn wrote: > On 1/31/15 1:07 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > > On Friday, January 30, 2015 22:03:02 Jonathan M Davis via > > Digitalmars-d-learn wrote: > >> Yeah. I really should add a unixTimeToSysTime function, > > > > Actually, maybe it should be a static function on SysTime called > > fromUnixTime to go with toUnixTime. I don't know. Regardless, it's a nicety > > that should be there, and I botched things by not having it. > > Might I suggest that you simply define an enum for UnixEpoch that's a > SysTime. Then you can do whatever you want. > > Note that unixTimeToSysTime doesn't help the OP, his timestamp is in > milliseconds since 1/1/1970. Then I should probably just do both - declare a function to do the conversion (since that's more user-friendly for the common case) and supply an enum for the unix epoch if someone is converting to something like milliseconds instead of seconds for the unix epoch. - Jonathan M Davis
Re: Time from timestamp?
On 2/2/15 10:06 AM, Jonathan M Davis via Digitalmars-d-learn wrote: On Monday, February 02, 2015 08:49:58 Steven Schveighoffer via Digitalmars-d-learn wrote: On 1/31/15 1:07 AM, Jonathan M Davis via Digitalmars-d-learn wrote: On Friday, January 30, 2015 22:03:02 Jonathan M Davis via Digitalmars-d-learn wrote: Yeah. I really should add a unixTimeToSysTime function, Actually, maybe it should be a static function on SysTime called fromUnixTime to go with toUnixTime. I don't know. Regardless, it's a nicety that should be there, and I botched things by not having it. Might I suggest that you simply define an enum for UnixEpoch that's a SysTime. Then you can do whatever you want. Note that unixTimeToSysTime doesn't help the OP, his timestamp is in milliseconds since 1/1/1970. Then I should probably just do both - declare a function to do the conversion (since that's more user-friendly for the common case) and supply an enum for the unix epoch if someone is converting to something like milliseconds instead of seconds for the unix epoch. You already have various unixTimeToXXX functions, so it's probably moot, but with an epoch, such operations are dead simple: auto t = UnixEpoch + time().seconds; I see very little value in a wrapper function to do this. But it's already there, so... BTW, I think with UFCS, having the 'seconds' etc. functions is one of the coolest parts of D's time library. I love that part :) -Steve
GDB C++ Tip
FYI http://stackoverflow.com/questions/28279395/printing-sub-class-members-in-gdb This is makes DMD debugging more enjoyable :)
Re: std.algorithm sort() and reverse() confusion
Jonathan M Davis: arr.reverse.map!sqrt Yes, but arguably, chaining calls in this case is bad, We have discussed this some time... and I'd like reverse() to return the original array (like the deprecated array .reverse property). It's not a perfect design, but allowing UFCS chains is quite important. Bye, bearophile
Re: Conway's game of life
gedaiu: https://github.com/gedaiu/Game-Of-Life-D A bare-bones implementation: http://rosettacode.org/wiki/Conway%27s_Game_of_Life#Faster_Version The quality of the D GC is not important for a simple Life implementation, you just need two arrays. Bye, bearophile
Re: how convert the range to slice ?
Nordlöw: Is started digging a bit... The magic happens at line 103 in cast.c. How do I most conveniently figure out which members (functions) a type (e->type) has? I figured I could check for typical InputRange members and issue a hint about using .array if e->type has them. It's probably better to ask such questions on GitHub (and to open an enhancement request in Bugzilla). Bye, bearophile
Re: how convert the range to slice ?
On Monday, 2 February 2015 at 16:56:02 UTC, bearophile wrote: Nordlöw: Is started digging a bit... The magic happens at line 103 in cast.c. How do I most conveniently figure out which members (functions) a type (e->type) has? I figured I could check for typical InputRange members and issue a hint about using .array if e->type has them. It's probably better to ask such questions on GitHub (and to open an enhancement request in Bugzilla). Bye, bearophile I cracked it. First proof of concept here https://github.com/nordlow/dmd/commit/40ce0ecf34f90c4d3053c47e9286d7574f596e15
Re: how convert the range to slice ?
On Monday, 2 February 2015 at 19:04:52 UTC, Nordlöw wrote: https://github.com/nordlow/dmd/commit/40ce0ecf34f90c4d3053c47e9286d7574f596e15 Made it PR at https://github.com/D-Programming-Language/dmd/pull/4371
Visual D prematurely closes the console
Hi.
Visual D are settings in the project parameter Subsystem mode
Console and command line with output still closes prematurely.
How to make the command line was not closed prematurely without
using system("pause")?
Re: Visual D prematurely closes the console
On 02/02/2015 01:51 PM, Dennis Ritchie wrote:
Hi.
Visual D are settings in the project parameter Subsystem mode
Console and command line with output still closes prematurely.
How to make the command line was not closed prematurely without
using system("pause")?
I think the answer is the same as Visual C++:
http://stackoverflow.com/questions/454681/how-to-keep-the-console-window-open-in-visual-c
Ali
Re: Visual D prematurely closes the console
On Monday, 2 February 2015 at 22:14:36 UTC, Ali Çehreli wrote: http://stackoverflow.com/questions/454681/how-to-keep-the-console-window-open-in-visual-c Not helped: http://i.imgur.com/4EG84YK.png
Re: Visual D prematurely closes the console
On Monday, 2 February 2015 at 22:58:06 UTC, Dennis Ritchie wrote: On Monday, 2 February 2015 at 22:14:36 UTC, Ali Çehreli wrote: http://stackoverflow.com/questions/454681/how-to-keep-the-console-window-open-in-visual-c Not helped: http://i.imgur.com/4EG84YK.png Use monoD do a hello world ,you will get the answer.
Re: Visual D prematurely closes the console
On Monday, 2 February 2015 at 23:08:13 UTC, FrankLike wrote: Use monoD do a hello world ,you will get the answer. And Mono-D good debugger?
Re: Visual D prematurely closes the console
I found the right option! http://imgur.com/KfkuBZi
Struct destructor in a with block
module main;
import std.stdio;
void main(string[] args)
{
with(test())
{
foo();
}
}
struct test
{
void foo()
{
writeln("foo");
}
~this()
{
writeln("destoy");
}
}
prints:
destroy
foo
Is this a bug?
Re: Struct destructor in a with block
On 02/02/2015 07:51 PM, Tofu Ninja wrote:
module main;
import std.stdio;
void main(string[] args)
{
with(test())
{
foo();
}
}
struct test
{
void foo()
{
writeln("foo");
}
~this()
{
writeln("destoy");
}
}
prints:
destroy
foo
Is this a bug?
Yes, it's a known bug that has been fixed on git head but I can't find
the bug report. :-/
The new output:
foo
destoy
Yes, without the 'r'. ;)
Ali
Re: Struct destructor in a with block
On Tuesday, 3 February 2015 at 05:09:55 UTC, Ali Çehreli wrote: Yes, it's a known bug that has been fixed on git head but I can't find the bug report. :-/ Ok cool, good to know. The new output: foo destoy Yes, without the 'r'. ;) Ali Yeah, i noticed the typo right after I posted...
