Re: DMDScript
On 07/11/2014 08:45 AM, Chris wrote:
Tried to compile on linux, got this error message (I guess I can fix it):
dmd -c textgen.d
textgen.d(36): Error: cannot implicitly convert expression (DMDScript
fatal runtime error: ) of type string to char[]
Here is the relevant parts:
struct Msgtable
{
char[] name;
int value;
char[] ident;
}
Msgtable errtable[] =
[
{ DMDScript fatal runtime error: , 0,
ERR_RUNTIME_PREFIX },
// ...
]
DMDScript was probably written for D1 and has never been ported to more
recent D.
Ali
Re: DMDScript
On Friday, 11 July 2014 at 15:45:42 UTC, Chris wrote: Tried to compile on linux, got this error message (I guess I can fix it): dmd -c textgen.d textgen.d(36): Error: cannot implicitly convert expression (DMDScript fatal runtime error: ) of type string to char[] .. bunch more errors. You might try https://github.com/DmitryOlshansky/DMDScript which, according to it's notes has changes to make it compatible with D2.
Re: OSX, Need help with Compiling and linking errors
On 7/13/2014 2:28 PM, Israel Rodriguez wrote: What about the dub libraries, what kind of errors do you get if you try to use a library not compatible for your system, say OSX or Linux? Im assuming the same linking errors but im not sure. dub doesn't download library binaries, but the source. It compiles each dependency along with your project (generally only once, unless you --force a rebuild or -upgrade the libraries) using the same compiler that is used to compile your source. So if any given library is using something that is unavailable on your platform, you will see compile-time errors rather than linker errors. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Re: Something like Python's psutils for D?
On Sunday, 13 July 2014 at 01:01:16 UTC, Ellery Newcomer wrote: would psutils itself be acceptable? https://bitbucket.org/ariovistus/pyd I haven't thought about this possibility, thanks.
Re: DStyle: Braces on same line
On 12/07/14 21:01, Danyal Zia via Digitalmars-d-learn wrote: I noticed that in Andrei's talks and his book, he used braces on the same line of delcaration, however Phobos and other D libraries I know use braces on their own line. Now I'm in a position where I need to take decision on coding style of my library and I get accustomed to use braces on same line but I'm worried if that would make my library less readable to other D users. Should I worry about it? Or is that's just a debatable style that won't really matter if it's persistent throughout library? As long as your coding style is self-consistent, then it really doesn't matter a lot. In particular this choice of bracing style is a very minor issue that people are well used to having to deal with. However, I do think there's value in deliberately matching the code style of the standard library, as it extends the volume of public D code with a common style. So unless you have a strong personal preference, I'd go with that.
std.algorithm.among
The idea of not making std.algorithm.among!() a predicate was not
so good:
void main() {
import std.stdio, std.algorithm;
auto s = hello how\nare you;
s.until!(c = c.among!('\n', '\r')).writeln;
}
(A normal workaround is to use !!c.among!).
Bye,
bearophile
Re: std.algorithm.among
On Sunday, 13 July 2014 at 11:18:05 UTC, bearophile wrote:
The idea of not making std.algorithm.among!() a predicate was
not so good:
void main() {
import std.stdio, std.algorithm;
auto s = hello how\nare you;
s.until!(c = c.among!('\n', '\r')).writeln;
}
(A normal workaround is to use !!c.among!).
Bye,
bearophile
```
s.until!(among!('\n', '\r')).writeln; // Error: cannot implicitly
convert expression (among(front(this._input))) of type uint to
bool
```
:-(
Re: DStyle: Braces on same line
On Sunday, 13 July 2014 at 10:18:23 UTC, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: However, I do think there's value in deliberately matching the code style of the standard library, as it extends the volume of public D code with a common style. So unless you have a strong personal preference, I'd go with that. I'm going with Andrei's style of preference on his talks ;)
Re: std.algorithm.among
On 07/13/2014 01:18 PM, bearophile wrote:
The idea of not making std.algorithm.among!() a predicate was not so good:
...
Agreed.
void main() {
import std.stdio, std.algorithm;
auto s = hello how\nare you;
s.until!(c = c.among!('\n', '\r')).writeln;
}
(A normal workaround is to use !!c.among!).
Bye,
bearophile
It works with filter, so I think it should just work with until as well.
Re: std.algorithm.among
Timon Gehr: It works with filter, so I think it should just work with until as well. So do you suggest me to open a bug report where I ask among to return a bool, or do you suggest to ask for an enhancement of until, or what? Bye, bearophile
Re: linux n00b
On Sunday, 13 July 2014 at 13:38:34 UTC, Xiaoxi wrote: If I want to build a d program which works on all dists, can i build that from any linux machine since dmd links statically by default or should I chose the oldest, i.e rhel5 to build on? because of possible glibc issues? Using machine with oldest glibc among all targets should generally work however recommended way to distribute software in Linux world is via distro-specific packages each built on own system. Common binary distributions are likely to work in most cases but no one gives you any guarantees for that - each distro is effectively a different operating system.
Re: DStyle: Braces on same line
On Sun, Jul 13, 2014 at 11:32:23AM +0200, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: On 12/07/14 21:01, Danyal Zia via Digitalmars-d-learn wrote: I noticed that in Andrei's talks and his book, he used braces on the same line of delcaration, however Phobos and other D libraries I know use braces on their own line. Now I'm in a position where I need to take decision on coding style of my library and I get accustomed to use braces on same line but I'm worried if that would make my library less readable to other D users. Should I worry about it? Or is that's just a debatable style that won't really matter if it's persistent throughout library? As long as your coding style is self-consistent, then it really doesn't matter a lot. In particular this choice of bracing style is a very minor issue that people are well used to having to deal with. However, I do think there's value in deliberately matching the code style of the standard library, as it extends the volume of public D code with a common style. So unless you have a strong personal preference, I'd go with that. I had my own style before, but after I started contributing to Phobos, I found it a pain to keep switching back and forth between styles (and to convert styles before submitting PR's), so eventually I decided to just adopt Phobos style for all my D code, including my personal projects. That way I never have to worry again about which project is in what style, but everything is consistently the same style. It also helps that my previous supervisor at my work also used a similar style, which was different from my own, so I already had to adapt my style to his in the past. That was what convinced me that other inferior styles than my own had any merit at all. ;-) At the end of the day, though, as long as your style is consistent within a project, it's Good Enough(tm). There are far weightier issues of semantics to worry about than fretting over syntax. T -- Verbing weirds language. -- Calvin ( Hobbes)
Re: Help to find crash in simple stack type?
On Saturday, 12 July 2014 at 17:11:00 UTC, Rainer Schuetze wrote: On 12.07.2014 19:05, Rainer Schuetze wrote: Thanks for the reduction. GC.realloc seems broken for reallocations to sizes larger than the current GC pool. Please file a bug report. Actually done that myself: https://issues.dlang.org/show_bug.cgi?id=13111 Thanks a lot guys!
Re: DStyle: Braces on same line
On Saturday, 12 July 2014 at 19:01:56 UTC, Danyal Zia wrote: Hi, I noticed that in Andrei's talks and his book, he used braces on the same line of delcaration, however Phobos and other D libraries I know use braces on their own line. Now I'm in a position where I need to take decision on coding style of my library and I get accustomed to use braces on same line but I'm worried if that would make my library less readable to other D users. Should I worry about it? Or is that's just a debatable style that won't really matter if it's persistent throughout library? Thanks Here is the 'official' style that is followed by most people including me. http://dlang.org/dstyle.html
Re: DStyle: Braces on same line
On 13/07/14 16:52, H. S. Teoh via Digitalmars-d-learn wrote: I had my own style before, but after I started contributing to Phobos, I found it a pain to keep switching back and forth between styles (and to convert styles before submitting PR's), so eventually I decided to just adopt Phobos style for all my D code, including my personal projects. That way I never have to worry again about which project is in what style, but everything is consistently the same style. Same here. :-) It also helps that my previous supervisor at my work also used a similar style, which was different from my own, so I already had to adapt my style to his in the past. That was what convinced me that other inferior styles than my own had any merit at all. ;-) Two consequences of adapting myself to Phobos style were that I realized (i)how little most of these things really matter, and (ii) pretty much any stylistic choice carries both benefits and drawbacks. E.g. in this case, Egyptian-style braces definitely make your code more compact, but separate-line opening braces definitely make it easier to see where scopes begin and end.
Re: DStyle: Braces on same line
On 13/07/14 14:23, Danyal Zia via Digitalmars-d-learn wrote: I'm going with Andrei's style of preference on his talks ;) Andrei can no doubt speak for himself about his preferences, but I'd be wary of assuming that the style he uses in his talks necessarily reflects his actual stylistic preference. As has been pointed out by others, same-line opening brace is a common style for slides and books because it saves vertical space; people will use it there even if in their actual code they prefer something different.
Re: DStyle: Braces on same line
On Sunday, 13 July 2014 at 16:47:00 UTC, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: On 13/07/14 14:23, Danyal Zia via Digitalmars-d-learn wrote: I'm going with Andrei's style of preference on his talks ;) Andrei can no doubt speak for himself about his preferences, but I'd be wary of assuming that the style he uses in his talks necessarily reflects his actual stylistic preference. As has been pointed out by others, same-line opening brace is a common style for slides and books because it saves vertical space; people will use it there even if in their actual code they prefer something different. Andrei has stated several times he prefers Phobos-style brackets but uses egyptian ones in slides / books because of spacing constraints.
Re: DStyle: Braces on same line
Danyal Zia: I noticed that in Andrei's talks and his book, he used braces on the same line of delcaration, however Phobos and other D libraries I know use braces on their own line. Rosettacode D examples always use the Egyptian style. For my code I use the same style, but Phobos contributions (and future ddmd) should put opening braces on their own line. Bye, bearophile
Re: DStyle: Braces on same line
On 07/13/2014 06:45 PM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: Two consequences of adapting myself to Phobos style were that I realized (i)how little most of these things really matter, and (ii) pretty much any stylistic choice carries both benefits and drawbacks. ... Wrong. There are things which are simply bad ideas. E.g. in this case, Egyptian-style braces definitely make your code more compact, I.e. you see where everything is. but separate-line opening braces definitely make it easier to see where scopes begin and end. This is the only argument I have heard in favour of doing this, but it is not actually valid. This critique might apply to Lisp style.
Re: DStyle: Braces on same line
On Sunday, 13 July 2014 at 17:24:40 UTC, Timon Gehr wrote: On 07/13/2014 06:45 PM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: Wrong. There are things which are simply bad ideas. E.g. in this case, Egyptian-style braces definitely make your code more compact, I.e. you see where everything is. Yes, the same argument for books and slides is also applicable to all other media. This style has also caught on amongst the other curly braced languages that I use, so that most of the code I read (and write) has adopted it (C/C++/Java/Javascript code, that is). The Phobos style is incredibly wasteful IMO, but that's what D has adopted, so if you intend to contribute to Phobos, you had better get used to it. The Rust community appears to have made the right choice with Egyptian for everything. but separate-line opening braces definitely make it easier to see where scopes begin and end. All of this is subjective, of course, but I definitely don't find that the Phobos style provides this advantage. This is the only argument I have heard in favour of doing this, but it is not actually valid. This critique might apply to Lisp style. Not sure I follow you here. Most of the Lisp I've read is indented like Python, the idea being that you learn not to not see all of the parens and rely on tools like paredit to do the trivial balancing. I'd hate to read Lisp with separate lines for parens that open scopes. I'm sure that's not what you mean!
Re: DStyle: Braces on same line
On 13/07/14 19:24, Timon Gehr via Digitalmars-d-learn wrote: Wrong. There are things which are simply bad ideas. I think that we can take it as read that I meant, Any reasonable stylistic choice. Of course, YMMV about what counts as reasonable, but most of the things that people fuss over are fairly minimal differences in practice. I.e. you see where everything is. Compactness can also be a disadvantage. Some people have a preference for a hyper-compact style where there are minimal blank lines in the code; I accept their goal as valid, and I think there are cases where it can surely help, but it's not one that I personally find very helpful. In fact, one reason that I've come to appreciate standard D style is the way in which separate opening braces actually help to space out the code into more obvious paragraphs. This is the only argument I have heard in favour of doing this, but it is not actually valid. This critique might apply to Lisp style. Well, I personally find that separate-line opening braces do make it easier to line up the opening and ending of scopes. If it doesn't do anything for you, that's a shame; but it doesn't make the argument invalid.
Re: std.algorithm.among
Timon Gehr:
I am saying the following code implementing 'until' in
std.algorithm is at fault:
private bool predSatisfied() // -- don't say bool here
{
static if (is(Sentinel == void))
return unaryFun!pred(_input.front); // or cast here
else
return startsWith!pred(_input, _sentinel); // and
here
}
https://issues.dlang.org/show_bug.cgi?id=13124
Bye,
bearophile
Re: DStyle: Braces on same line
On 07/13/2014 07:51 PM, Brian Rogoff wrote: On Sunday, 13 July 2014 at 17:24:40 UTC, Timon Gehr wrote: On 07/13/2014 06:45 PM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: Wrong. There are things which are simply bad ideas. E.g. in this case, Egyptian-style braces definitely make your code more compact, I.e. you see where everything is. Yes, the same argument for books and slides is also applicable to all other media. Exactly. This style has also caught on amongst the other curly braced languages that I use, so that most of the code I read (and write) has adopted it (C/C++/Java/Javascript code, that is). The Phobos style is incredibly wasteful IMO, but that's what D has adopted, so if you intend to contribute to Phobos, you had better get used to it. The Rust community appears to have made the right choice with Egyptian for everything. ... Yup, but they also do horrible things like using '+' to denote intersection (multiple trait bounds). but separate-line opening braces definitely make it easier to see where scopes begin and end. All of this is subjective, of course, but I definitely don't find that the Phobos style provides this advantage. This is the only argument I have heard in favour of doing this, but it is not actually valid. This critique might apply to Lisp style. Not sure I follow you here. Most of the Lisp I've read is indented like Python, the idea being that you learn not to not see all of the parens and rely on tools like paredit to do the trivial balancing. I'd hate to read Lisp with separate lines for parens that open scopes. I'm sure that's not what you mean! I was suggesting that if someone does this: http://en.wikipedia.org/wiki/Indent_style#Lisp_style Then I would have an easier time seeing where a person is coming from who claims that it makes it in some way harder to see at a glance where scopes begin and end.
Re: DStyle: Braces on same line
On 13/07/14 19:51, Brian Rogoff via Digitalmars-d-learn wrote: Yes, the same argument for books and slides is also applicable to all other media. Not really. In a book or a slide you have an unavoidable constraint on how much vertical space you can take up. On a screen, you are unavoidably going to have to scroll up or down at some point; it's just a question of how often. Scrolling media (not just code) allow you to make a tradeoff between less vertically compact styles that better highlight different semantic blocks, versus more compact styles that packs more data into one screen's worth of lines, while usually making it less easy to highlight the semantics of what's being displayed. You may lean towards favouring compact code over other factors, but at the end of the day this is a preference based on your personal priorities, not a hard and fast rule.
SImple C++ code to D
I have this code in C++
//...
char image[0x800];
//...
auto dosh = reinterpret_castIMAGE_DOS_HEADER*(image[0]);
dosh-e_magic = *(WORD*)MZ;
dosh-e_cblp = 0x90;
dosh-e_cp = 3;
dosh-e_cparhdr = 4;
dosh-e_maxalloc = 0x;
dosh-e_sp = 0xb8;
dosh-e_lfarlc = 0x40;
dosh-e_lfanew = 0x80;
BYTE stub[] = { 0xb8, 0x01, 0x4c, 0xcd, 0x21 };
memcpy(image[0x40], stub, sizeof(stub));
I maded this in D:
module main;
import std.stdio;
import std.c.windows.windows;
struct _IMAGE_DOS_HEADER
{
WORD e_magic;
WORD e_cblp;
WORD e_cp;
WORD e_crlc;
WORD e_cparhdr;
WORD e_minalloc;
WORD e_maxalloc;
WORD e_ss;
WORD e_sp;
WORD e_csum;
WORD e_ip;
WORD e_cs;
WORD e_lfarlc;
WORD e_ovno;
WORD e_res[4];
WORD e_oemid;
WORD e_oeminfo;
WORD e_res2[10];
LONG e_lfanew;
}
alias IMAGE_DOS_HEADER = _IMAGE_DOS_HEADER;
alias PIMAGE_DOS_HEADER = _IMAGE_DOS_HEADER*;
char image[0x800];
void main(string[] args)
{
auto dosh = cast(IMAGE_DOS_HEADER*)image[0];
//dosh.e_magic = 0x5A4D;
dosh.e_magic = cast(WORD*)(MZ);
auto stub = [0xb8, 0x01, 0x4c, 0xcd, 0x21];
dmemcpy(image[0x40], stub, stub.sizeof);
}
void * dmemcpy ( void * destination, const void * source, size_t
num ) pure nothrow
{
(cast(ubyte*)destination)[0 ..
num][]=(cast(const(ubyte)*)source)[0 .. num];
return destination;
}
But I got errors in this:
dmemcpy(image[0x40], stub, stub.sizeof);
and in the cast of MZ to Word*
How is the best way to solve this ?
Re: std.algorithm.among
On Sunday, 13 July 2014 at 11:18:05 UTC, bearophile wrote:
The idea of not making std.algorithm.among!() a predicate was
not so good:
void main() {
import std.stdio, std.algorithm;
auto s = hello how\nare you;
s.until!(c = c.among!('\n', '\r')).writeln;
}
(A normal workaround is to use !!c.among!).
Bye,
bearophile
That's weird, I always assumed this worked. Was it always the
case that numeric types can't be implicitly casted to bool?
Re: std.algorithm.among
On 07/13/2014 08:51 PM, Meta wrote: That's weird, I always assumed this worked. Was it always the case that numeric types can't be implicitly casted to bool? Yes, unless their range fits into [0,2).
Re: std.algorithm.among
On Sunday, 13 July 2014 at 19:06:29 UTC, Timon Gehr wrote:
On 07/13/2014 08:51 PM, Meta wrote:
That's weird, I always assumed this worked. Was it always the
case that
numeric types can't be implicitly casted to bool?
Yes, unless their range fits into [0,2).
It seems that not even that is the case.
void main()
{
uint n = 0;
//Error
bool b = n;
}
Re: SImple C++ code to D
On Sunday, 13 July 2014 at 18:48:01 UTC, Alexandre wrote: dosh.e_magic = cast(WORD*)(MZ); should be: dosh.e_magic = cast(WORD*)(MZ.ptr);
Re: SImple C++ code to D
Alexandre:
WORD e_res[4];
In D it's better to write:
WORD[4] e_res;
char image[0x800];
Note this is a thread-local variable. If you need a module-local
variable you have to write:
__gshared char[0x800] image;
void main(string[] args)
If you don't need the args, then write:
void main()
In D we usually indent using 4 spaces.
auto dosh = cast(IMAGE_DOS_HEADER*)image[0];
Perhaps better (untested):
auto dosh = cast(IMAGE_DOS_HEADER*)image.ptr;
dosh.e_magic = cast(WORD*)(MZ);
Try (assuming word is 2 bytes long):
dosh.e_magic = cast(WORD*)MZ.ptr;
auto stub = [0xb8, 0x01, 0x4c, 0xcd, 0x21];
Try to use:
immutable ubyte[5] stub = [0xb8, 0x01, 0x4c, 0xcd, 0x21];
dmemcpy(image[0x40], stub, stub.sizeof);
}
void * dmemcpy ( void * destination, const void * source,
size_t num ) pure nothrow
{
(cast(ubyte*)destination)[0 ..
num][]=(cast(const(ubyte)*)source)[0 .. num];
return destination;
}
In D most cases you can avoid to use void as argument type.
Also try to minimize the use of casts.
And in D the * of pointers is written on the left, so you write
int* p and not int *p.
Also in that function you don't mutate num, so put a in
before size_t.
But I got errors in this:
dmemcpy(image[0x40], stub, stub.sizeof);
What errors?
Your code with some changes, but more improvements are possible
(untested):
import std.stdio;
import core.stdc.string;
import std.c.windows.windows;
struct IMAGE_DOS_HEADER {
WORD e_magic,
e_cblp,
e_cp,
e_crlc,
e_cparhdr,
e_minalloc,
e_maxalloc,
e_ss,
e_sp,
e_csum,
e_ip,
e_cs,
e_lfarlc,
e_ovno;
WORD[4] e_res;
WORD e_oemid;
WORD e_oeminfo;
WORD[10] e_res2;
LONG e_lfanew;
}
alias PIMAGE_DOS_HEADER = IMAGE_DOS_HEADER*;
__gshared char[0x800] image;
void main() {
auto dosh = cast(IMAGE_DOS_HEADER*)image.ptr;
dosh.e_magic = cast(WORD)*MZ.ptr;
immutable stub = xb8 01 4c cd 21;
memcpy(image[IMAGE_DOS_HEADER.sizeof], stub.ptr,
stub.length);
}
Bye,
bearophile
Re: SImple C++ code to D
On Sunday, 13 July 2014 at 18:48:01 UTC, Alexandre wrote: char image[0x800]; Better use `ubyte[0x800] image` here. `char[]` is only for UTF-8 strings.
Re: SImple C++ code to D
Marc Schütz: Better use `ubyte[0x800] image` here. `char[]` is only for UTF-8 strings. Right, sorry. Bye, bearophile
Re: std.algorithm.among
Meta:
It seems that not even that is the case.
void main()
{
uint n = 0;
//Error
bool b = n;
}
D doesn't carry the range of mutable variables across different
expressions.
So write (with the 2.066beta3):
void main() {
const uint x1 = 0;
const uint x2 = 1;
bool b1 = x1;
bool b2 = x2;
}
Bye,
bearophile
Re: Passing Templated Function Arguments Solely by Reference
On Friday, 11 July 2014 at 17:43:53 UTC, Ali Çehreli wrote: Ali Thx
Re: SImple C++ code to D
Ok, thanks thanks!!! Have a lot of thinks I need to learn When I generate the exe file, something is wrong with this: dosh.e_magic = cast(WORD)*MZ.ptr; When the PE file is generate in EXE have just the M of MZ...
Re: SImple C++ code to D
On 07/13/2014 05:21 PM, Alexandre wrote:
Ok, thanks thanks!!!
Have a lot of thinks I need to learn
When I generate the exe file, something is wrong with this:
dosh.e_magic = cast(WORD)*MZ.ptr;
When the PE file is generate in EXE have just the M of MZ...
You put the * outside the cast. bearophile had
dosh.e_magic = cast(WORD*)MZ.ptr;
However, one needs to copy the content to e_magic, which happens to be a
WORD. The endianness may be off but it should be something like this:
import std.stdio;
void main()
{
alias WORD = ushort;
WORD w = *cast(WORD*)MZ.ptr;
writefln(%02x, w);
}
Ali
Compile time regex matching
Hi I am trying to write some code that uses and matches to regular expressions at compile time, but the compiler won't let me because matchFirst and matchAll make use of malloc(). Is there an alternative that I can use that can be run at compile time? Thanks in advance. Jason
Re: SImple C++ code to D
Alexandre:
When the PE file is generate in EXE have just the M of MZ...
Let's try again, is this better?
import std.c.windows.windows: WORD, LONG;
struct IMAGE_DOS_HEADER {
WORD e_magic = ('M' 8) + 'Z',
e_cblp,
e_cp,
e_crlc,
e_cparhdr,
e_minalloc,
e_maxalloc,
e_ss,
e_sp,
e_csum,
e_ip,
e_cs,
e_lfarlc,
e_ovno;
WORD[4] e_res;
WORD e_oemid,
e_oeminfo;
WORD[10] e_res2;
LONG e_lfanew;
}
alias PIMAGE_DOS_HEADER = IMAGE_DOS_HEADER*;
__gshared ubyte[0x800] image;
void main() {
import std.stdio;
import core.stdc.string;
auto dosh = cast(PIMAGE_DOS_HEADER)image.ptr;
immutable stub = xb8 01 4c cd 21;
memcpy(image[IMAGE_DOS_HEADER.sizeof],
stub.ptr, stub.length);
}
Bye,
bearophile
Re: SImple C++ code to D
Oh, thanks a lot!!
With a little change all work!
look:
struct IMAGE_DOS_HEADER {
WORD e_magic,
e_cblp,
//...
void main() {
import std.stdio;
import std.file;
import core.stdc.string;
auto dosh = cast(PIMAGE_DOS_HEADER)image.ptr;
dosh.e_magic = ('Z' 8) + 'M';
immutable stub = xb8 01 4c cd 21;
memcpy(image[IMAGE_DOS_HEADER.sizeof],stub.ptr, stub.length);
std.file.write(a.exe, image);
}
Re: std.algorithm.among
On Sunday, 13 July 2014 at 20:55:25 UTC, bearophile wrote: D doesn't carry the range of mutable variables across different expressions. What is the reasoning behind this kind of special-casing?
Re: Setting dates
On Friday, July 11, 2014 04:01:24 Joel via Digitalmars-d-learn wrote: I've been trying to set a date for my program (a small struct): import std.datetime; auto date = cast(DateTime)Clock.currTime(); setDate(date.day, date.month, date.year); Problem is that day month are not integers. And date.day.to!int doesn't work either. You're going to need to provid more details. SetDate is not a standard function, so it must be yours, and we don't know anything about it - not even its signature, which makes it awfully hard to help you. That being said, date.day returns ubyte, date.month returns std.datetime.Month, and date.year returns ushort, all of which implicitly convert to int. So, I don't see why you would be having an problems converting them to int. This compiles just fine int year = date.year; int month = date.month; int day = date.day; And date.day.to!int or date.day.to!int() both compile just fine as long as you import std.conv. But calling to!int() is completely unnecessary, because the conversion is implicit, as show above. So, without more details, we can't help you. - Jonathan M Davis
