Steps to reproduce:
1. Download
[0.7.5](https://github.com/Pure-D/serve-d/releases/download/v0.7.5/serve-d_0.7.5-linux-x86_64.tar.xz). Extract. Run.
Segment Fault (Core Dumped). No information.
2. Download
[0.7.4](https://github.com/Pure-D/serve-d/releases/download/v0.7.4/serve-d_0.7.4-linux
On Wednesday, 9 April 2025 at 01:23:01 UTC, Salih Dincer wrote:
On Tuesday, 8 April 2025 at 20:14:56 UTC, Andy Valencia wrote:
p.s. Ironically, I could probably have coded a getopt in less
time than I've spent on std.getopt...
:)
Please try the following example with the parameters -h, -e,
On Tuesday, 8 April 2025 at 20:14:56 UTC, Andy Valencia wrote:
p.s. Ironically, I could probably have coded a getopt in less
time than I've spent on std.getopt...
:)
Please try the following example with the parameters -h, -e, -l,
and -v in that order:
```d
import std.array : appender;
im
I think that you are almost there.
https://dlang.org/phobos/std_getopt.html#.defaultGetoptFormatter
Try using: https://dlang.org/phobos/std_stdio.html#.File.lockingTextWriter
``defaultGetoptFormatter(stderr.lockingTextWriter, "heading",
helpInformation.options);``
This seems like something which needs to be straightforward, and
yet I've spent a good amount of time getting nowhere.
How does one get the usage information which getopt embeds in a
result, and spit it out to stderr? The internals show some help
output, hard-coded to stdout. As any Posix CL
On Tuesday, 8 April 2025 at 15:54:52 UTC, Timon Gehr wrote:
In any case, casting a memory allocator to `pure` should be
fine. Any reasonable definition of `pure` we can come up with
in the future would be compatible with that.
Yes, this is also what I think. Of course an allocator cannot be
s
On Tuesday, April 8, 2025 9:07:45 AM MDT Guillaume Piolat via
Digitalmars-d-learn wrote:
> On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
> > Of course, I'm also increasingly of the opinion that pure was a
> > mistake in general, because it does almost nothing in practice
> > bu
On 4/8/25 17:07, Guillaume Piolat wrote:
On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
Of course, I'm also increasingly of the opinion that pure was a
mistake in general, because it does almost nothing in practice but
routinely doesn't work with straightforward code - and it
On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
Of course, I'm also increasingly of the opinion that pure was a
mistake in general, because it does almost nothing in practice
but routinely doesn't work with straightforward code - and it's
definitely one of those attributes whi
On Sunday, April 6, 2025 9:30:31 AM MDT Anonymouse via Digitalmars-d-learn
wrote:
> I'm using `dub build -b docs` as a way to detect when I did ddoc
> wrong, such as mismatching `Params` sections and actual parameter
> names.
>
> Sadly one of the dependencies I (indirectly) use already *has*
> inc
On Tuesday, 8 April 2025 at 14:00:56 UTC, Jonathan M Davis wrote:
You basically have to lie to the compiler and cast the function
pointer to pure [...].
That being said, core.memory has pureMalloc and pureFree which
do that for you already, including mucking around with errno to
ensure that
On Tuesday, April 8, 2025 5:28:57 AM MDT Dom DiSc via Digitalmars-d-learn wrote:
> Hi.
>
> I want to create my own allocator, but using malloc is not pure
> (it internally has to have some "global state"). But the GC also
> has this "global state" and still is considered "pure".
> So internally the
Hi.
I want to create my own allocator, but using malloc is not pure
(it internally has to have some "global state"). But the GC also
has this "global state" and still is considered "pure".
So internally the impurity of the allocators has been hidden.
How can I do this?
adding @trusted doesn't
13 matches
Mail list logo