Re: any chance to get it working on windows xp?
On Monday, 18 May 2020 at 05:36:01 UTC, Mike Parker wrote: [...] Unfortunately, the minimum Windows version "officially" supported is Windows 7: https://forum.dlang.org/post/ktfgps$2ghh$1...@digitalmars.com With no testing on XP, you are bound to run into difficulties trying to use the tools there. So yeah, your best bet is using a compiler version that works and see if building dub from source makes a difference. If you can't get dub to work, then you'll want to look into using rdmd, which has shipped with dmd for years now, or perhaps makefiles. [...] This is not exactly a reply to the original thread, but maybe it helps someone who has searched for "Windows XP" in the forum and found this discussion. For version 2.094, dmd.exe and dub.exe require Windows Vista or Windows 7 or newer. We can make these tools support Windows XP (and possibly Windows 2000 too) by patching them as follows: - at offset 148h (offset 40h from the "PE" signature), we change 06h to 05h; - at offset 150h (offset 48h from the "PE" signature), we change 06h to 05h; - in both dmd.exe and dub.exe. (This support has not been thoroughly tested, but I seem to be able to build and run simple applications using Windows XP.) lld-link.exe also requires Windows Vista or 7 or newer, but I am too noob to make it support Windows XP. ddemangle.exe, dustmite.exe, libcurl.dll, optlink.exe and rdmd.exe all support older versions of Windows (at least, they support Windows XP). (All the .exe files mentioned above are the 32-bit ones located in the "windows\bin" subfolder, not the 64-bit ones located in the "windows\bin64" subfolder etc.) Good luck ! (Contact: DoctorNoobingstoneIPresume at gmail dot com)
Re: std/process.d: nothrow functions which throw (in struct ProcessPipes)
Steven Schveighoffer, Adam D. Ruppe, I wish to thank you both for your explanations ! I have understood and I have created a small test program. Indeed, at least on Windows, the destructor of an automatic struct does not seem to run. Have a wonderful day... and I hope to be bugging the community again soon !
std/process.d: nothrow functions which throw (in struct ProcessPipes)
Hello All,
In phobos/std/process.d, in the ProcessPipes struct, we can see a
few functions which are marked with "nothrow", but which (under
some conditions) throw:
@property File stdout() @safe nothrow
{
if ((_redirectFlags & Redirect.stdout) == 0)
throw new Error("Child process' standard output
stream hasn't "
~"been redirected.");
return _stdout;
}
Would it be possible to explain this, please ? Or point me to
some relevant documentation, please ?
Thank you.
Re: Should the "front" range primitive be "const" ?
On Monday, 19 March 2018 at 00:50:06 UTC, Jonathan M Davis wrote: [...] http://jmdavisprog.com/articles/why-const-sucks.html I have just read the reply and the article. I cannot believe you have written this article in response to this thread (perhaps I am mis-interpreting the date of the article). But even if not so, thank you for clarifications and for describing root causes. I will have to read it again, and then read the other replies to my question, because I am just beginning to understand what "head-const" and "tail-const" mean and to get an idea of the problems. By this reply, I just wish to let you all know that your answers are really appreciated and that I believe they are very helpful for many programmers, even if they need time to understand them. Thank you Jonathan. Thank you all.
Re: Should the "front" range primitive be "const" ?
On Monday, 19 March 2018 at 00:50:06 UTC, Jonathan M Davis wrote: On Monday, March 19, 2018 00:14:11 Drone1h via Digitalmars-d-learn wrote: I am not sure whether I can make it work with "inout" instead of "const". Perhaps I am missing something. ... May I ask that you confirm that this is what you suggested ? Thank you. Marking a empty or front with inout has most of the problems that const has. The difference is that [...] Thank you again for your kind replies. I will carefully read during the following days.
Re: Should the "front" range primitive be "const" ?
First of all, thank you all for the replies. It has taken me some
time to learn a bit more to be able to understand at least some
parts of them. I have a further question below the quotes.
On Tuesday, 30 January 2018 at 01:20:09 UTC, Jonathan M Davis
wrote:
On Tuesday, January 30, 2018 01:05:54 Drone1h via
Digitalmars-d-learn wrote:
[...]
I am trying to implement a ("struct template" ? what is the
correct word ?) range that just forwards its primitives
("empty",
"front", "popFront") to another range, possibly with some very
limited filtering/alteration, as std.range.Take (just to
learn).
Initially, the "front" member function (property) used to be
declared "const", but that was not accepted when the underlying
range (denoted "R" in the code below) was
std.stdio.File.ByChunk
("Error: mutable method std.stdio.File.ByChunk.front is not
callable using a const object").
[...]
If you want to put an attribute on it, inout is better, because
then it will work with any constness
I am not sure whether I can make it work with "inout" instead of
"const". Perhaps I am missing something.
Here is my code:
auto Take2 (R) (R r, size_t n)
{
import std.range.primitives;
struct Result
{
private:
R _r;
size_t _n;
size_t _i;
public:
@property bool empty () const
{
return _i >= _n || _r.empty;
}
@property auto ref front () const // Replace "const"
with "inout" here ?
{
return _r.front;
}
void popFront ()
{
++_i;
if (_i < _n)
_r.popFront ();
}
this (R r, size_t n)
{
_r = r;
_n = n;
_i = 0;
}
}
return Result (r, n);
}
unittest
{
import std.stdio;
auto file = File ("Example", "rb");
foreach (c; file.byChunk (0x100).Take2 (5))
stdout.rawWrite (c);
}
I get compile error:
Error: mutable method `std.stdio.File.ByChunkImpl.front` is
not callable using a `const` object
If I replace "const" with "inout" for the "front" function, i.e.
"@property auto ref front () inout", I get similar error:
Error: mutable method `std.stdio.File.ByChunkImpl.front` is
not callable using a `inout` object
May I ask that you confirm that this is what you suggested ?
Thank you.
[...] const ranges are utterly useless, because they can't be
mutated and thus can't be iterated. [...]
I am considering a function that takes as parameter a (reference
to) const range. It should be able to check whether the range is
"empty" and, if not empty, it should be able to access the
"front" element.
Now the caller of that function can rest assured that the
function is not going to modify the range by "popFront".
The function might be more useful than a function that just takes
as parameter a value (the result of "front") because it may be
called with an empty range and it can detect that. This is
similar to getting as parameter a (possibly null) pointer to a
value instead of getting as parameter a value.
Therefore, it seems to me that a const range might be useful.
If you have already considered this and have actually seen
one-step ahead of me, may I ask that you confirm, please ?
Thank you respectfully.
Should the "front" range primitive be "const" ?
Hello all,
I am trying to implement a ("struct template" ? what is the
correct word ?) range that just forwards its primitives ("empty",
"front", "popFront") to another range, possibly with some very
limited filtering/alteration, as std.range.Take (just to learn).
Initially, the "front" member function (property) used to be
declared "const", but that was not accepted when the underlying
range (denoted "R" in the code below) was std.stdio.File.ByChunk
("Error: mutable method std.stdio.File.ByChunk.front is not
callable using a const object").
Is there any value in having the "front" range primitive declared
to be a "const" member function ?
And if so, is the following implementation okay ? Could it be
further simplified ?
struct Taker (R)
{
private R _r;
...
static if (functionAttributes ! (R.front) &
FunctionAttribute.const_)
public @property auto front () const { return
_r.front; }
else
public @property auto front () { return
_r.front; }
...
}
Thank you respectfully !
Drone1h
