Assume a third-party API of the following signature:
T* next(I iter);
which advances an iterator of sorts and returns the next element, or
null when iteration is done. No other information about the state of the
iterator is available.
I wish to adapt this interface to a forward range
On Sunday, 21 April 2024 at 08:44:38 UTC, alex wrote:
Hi guys. Trying to play with vibe-d and want to create separate
web app, and cli app which can add admin users. When I just
keep both files app.d and cli.d in source folder, I get an
error that I can't have more then 1 main function.
On Sunday, 21 April 2024 at 14:57:33 UTC, Paolo Invernizzi wrote:
Hi,
Someone can point me to a D implementation of the classical
OpenCV find homography matrix?
Thank you,
Paolo
Kinda some work but it should be doable using DCV and mir.lubeck
in theory
DCV can compute, not sift or surf
On Sunday, 21 April 2024 at 08:44:38 UTC, alex wrote:
Hi guys. Trying to play with vibe-d and want to create separate
web app, and cli app which can add admin users. When I just
keep both files app.d and cli.d in source folder, I get an
error that I can't have more then 1 main function.
Hi guys. Trying to play with vibe-d and want to create separate
web app, and cli app which can add admin users. When I just keep
both files app.d and cli.d in source folder, I get an error that
I can't have more then 1 main function.
I already asked chatGPT, and it replied that I need to use
On Friday, 19 April 2024 at 22:24:17 UTC, Liam McGillivray wrote:
```
template enumMixin(alias Enum) {
static foreach(m; __traits(allMembers, Enum)) static if
(!__traits(isDeprecated, __traits(getMember, Enum, m)))
{
mixin("alias "~m~" = __traits(getMember, Enum, m);");
}
Well, someone on the Discord server has been helping me attempt
this, but while I managed to get a solution that compiles without
errors, I still get the deprecation warning.
Here is what I ended up with:
```
template enumMixin(alias Enum) {
static foreach(m; __traits(allMembers, Enum))
I know that DStep generates CTFE functions to automatically make
aliases for enum members so that the can be used without the enum
name, as is done in C. DStep does it with a CTFE function, though
it should also be possible with a mixin template.
Here is my attempt so far, using a mixin
On 20/04/2024 9:28 AM, Ivan Kazmenko wrote:
Hi.
I'd like to test locally whether a commit
(https://github.com/dlang/dmd/pull/16400) fixes an issue
(https://issues.dlang.org/show_bug.cgi?id=24440). The GitHub
instructions in the PR tell to use Digger for a quick and easy check,
but it fails
On Thursday, 18 April 2024 at 11:05:07 UTC, yabobay wrote:
On Wednesday, 17 April 2024 at 15:24:07 UTC, Ferhat Kurtulmuş
wrote:
On Wednesday, 17 April 2024 at 11:03:22 UTC, yabobay wrote:
I'm using [dray](https://code.dlang.org/packages/dray) in my
project with dub, here's the relevant parts
On Wednesday, 17 April 2024 at 15:24:07 UTC, Ferhat Kurtulmuş
wrote:
On Wednesday, 17 April 2024 at 11:03:22 UTC, yabobay wrote:
I'm using [dray](https://code.dlang.org/packages/dray) in my
project with dub, here's the relevant parts of the dub.json:
[...]
İt seems your issue is related to
On Thursday, 11 April 2024 at 16:23:44 UTC, Andy Valencia wrote:
[...]
void
main(in string[] argv)
^^
What if you want to use
bool memorymapped;
getopt (argv, "m", );
inside main? [1]
Have you tried using "rm" [2] instead of "r" as stdioOpenmode
under Linux
for a "no code"
On Wednesday, 17 April 2024 at 03:13:46 UTC, Liam McGillivray
wrote:
On Wednesday, 17 April 2024 at 02:39:25 UTC, Paul Backus wrote:
This is called [row polymorphism][1], and it does not exist in
D.
You could approximate it by making `someFunction` a template,
and accepting any type `T` that
On Wednesday, 17 April 2024 at 11:03:22 UTC, yabobay wrote:
I'm using [dray](https://code.dlang.org/packages/dray) in my
project with dub, here's the relevant parts of the dub.json:
[...]
İt seems your issue is related to the raylib itself, neither the
binding you use nor the d programming
I'm using [dray](https://code.dlang.org/packages/dray) in my
project with dub, here's the relevant parts of the dub.json:
```json
"dependencies" : {"dray": "~>4.2.0-r3"},
"dflags-ldc": ["--static"],
"lflags": ["-static"]
```
In my regular setup with Debian, i can compile and run my
On Wednesday, 17 April 2024 at 00:40:28 UTC, Alex Bryan wrote:
If you're not using gdc exclusively, you'll want to take a look
at this: https://github.com/dlang/dub/pull/2818
I knew there was something wrong there.
On Wednesday, 17 April 2024 at 03:13:46 UTC, Liam McGillivray
wrote:
Is there a way I can replace "`TypeB`" in the function
parameters with another symbol, and then define that symbol to
accept `TypeB` as an argument, but also accept `TypeA` which
would get converted to `TypeB` using a
On Wednesday, 17 April 2024 at 02:39:25 UTC, Paul Backus wrote:
This is called [row polymorphism][1], and it does not exist in
D.
You could approximate it by making `someFunction` a template,
and accepting any type `T` that has the necessary members
instead of only accepting `typeB`. But
On Wednesday, 17 April 2024 at 01:36:59 UTC, Liam McGillivray
wrote:
To better understand what I mean, take the following example,
where I have a function, and two structs.
```
struct typeA {
// Some member variables here
}
struct typeB {
// Some similar member variables here, but in a
I have two structs that serve roughly the same purpose, and I
would like one to be accepted when the other is declared as a
function parameter.
To better understand what I mean, take the following example,
where I have a function, and two structs.
```
struct typeA {
// Some member
If you're not using gdc exclusively, you'll want to take a look
at this: https://github.com/dlang/dub/pull/2818
On Monday, 15 April 2024 at 08:05:25 UTC, Patrick Schluter wrote:
The setup of a memory mapped file is relatively costly. For
smaller files it is a net loss and read/write beats it hands
down.
Interestingly, this performance deficit is present even when run
against the largest conveniently
On Thursday, 11 April 2024 at 00:24:44 UTC, Andy Valencia wrote:
I wrote a "count newlines" based on mapped files. It used
about twice the CPU of the version which just read 1 meg at a
time. I thought something was amiss (needless slice
indirection or something), so I wrote the code in C.
On 15/04/2024 10:36 AM, Liam McGillivray wrote:
Well, it did work when I tried it (using a string variable, not a
literal of course). It displayed as it is supposed to. But from the
information I can find on the web it looks like strings are sometimes
but not |always| zero-terminated. Not a
On Sunday, 14 April 2024 at 22:36:18 UTC, Liam McGillivray wrote:
On Friday, 12 April 2024 at 15:24:38 UTC, Steven Schveighoffer
wrote:
```d
void InitWindow(int width, int height, ref string title) {
InitWindow(width, height, cast(const(char)*)title);
}
```
This is invalid, a string may
On Friday, 12 April 2024 at 15:24:38 UTC, Steven Schveighoffer
wrote:
```d
void InitWindow(int width, int height, ref string title) {
InitWindow(width, height, cast(const(char)*)title);
}
```
This is invalid, a string may not be zero-terminated. You can't
just cast.
Well, it did work
On Saturday, 13 April 2024 at 22:00:16 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 13 April 2024 at 21:41:41 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 13 April 2024 at 21:39:10 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 13 April 2024 at 21:21:24 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On Saturday, 13 April 2024 at 21:41:41 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 13 April 2024 at 21:39:10 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 13 April 2024 at 21:21:24 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 14/04/2024 8:59 AM, Ferhat Kurtulmuş wrote:
These don't work for me:
On Saturday, 13 April 2024 at 21:39:10 UTC, Ferhat Kurtulmuş
wrote:
On Saturday, 13 April 2024 at 21:21:24 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 14/04/2024 8:59 AM, Ferhat Kurtulmuş wrote:
These don't work for me:
"dflags": ["-Iinclude"]
"importPaths": [
"include"
],
The
On Saturday, 13 April 2024 at 21:21:24 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 14/04/2024 8:59 AM, Ferhat Kurtulmuş wrote:
These don't work for me:
"dflags": ["-Iinclude"]
"importPaths": [
"include"
],
The importc docs do not help either.
Appears it hasn't been documented in
On Saturday, 13 April 2024 at 21:21:24 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 14/04/2024 8:59 AM, Ferhat Kurtulmuş wrote:
These don't work for me:
"dflags": ["-Iinclude"]
"importPaths": [
"include"
],
The importc docs do not help either.
Appears it hasn't been documented in
On 14/04/2024 8:59 AM, Ferhat Kurtulmuş wrote:
These don't work for me:
"dflags": ["-Iinclude"]
"importPaths": [
"include"
],
The importc docs do not help either.
Appears it hasn't been documented in new dub docs.
It is ``cSourcePaths`` and ``cImportPaths``.
These don't work for me:
"dflags": ["-Iinclude"]
"importPaths": [
"include"
],
The importc docs do not help either.
On Friday, 12 April 2024 at 03:57:40 UTC, John Dougan wrote:
Not every day you get to blame a compiler bug.
D is uniquely: hacky, expressive and buggy.
Having more metaprograming then c++ without the raw man power
comes at a cost, in d you should distrust the spec and instead
see what the
On Friday, 12 April 2024 at 15:08:50 UTC, Steven Schveighoffer
wrote:
On Friday, 12 April 2024 at 03:57:40 UTC, John Dougan wrote:
What is the procedure for bug reporting? I'm looking at the
issues tracker and have no clue how to drive the search to see
if this is already there.
On Friday, 12 April 2024 at 18:36:13 UTC, Chris Piker wrote:
On Saturday, 30 March 2024 at 07:11:49 UTC, Mike Parker wrote:
Though I appreciate the sentiment, it's much more effective
and efficient for people actually using the feature, and who
appreciate it, to write up a blog post about it
On Friday, 12 April 2024 at 18:45:21 UTC, Chris Piker wrote:
Even though DMD can't compile some C code, that's pretty much a
non-issue for me anyway. In my environment the servers are all
Linux so "apt-get" (or equivalent) typically provides a
pre-compiled dependency. Being able to list a
On Monday, 1 April 2024 at 02:08:20 UTC, Lance Bachmeier wrote:
On Saturday, 30 March 2024 at 05:01:32 UTC, harakim wrote:
It works well if you only need to work with a header. There are
still a few rough edges that get in the way if you're compiling
the full C sources (I filed bugs for all of
On Saturday, 30 March 2024 at 07:11:49 UTC, Mike Parker wrote:
Though I appreciate the sentiment, it's much more effective and
efficient for people actually using the feature, and who
appreciate it, to write up a blog post about it somewhere and
share that on Twitter/Reddit/HN, etc.
I would,
On Friday, 12 April 2024 at 00:04:48 UTC, Liam McGillivray wrote:
Here's what I wanted to do.
In the library I'm working on, there are various declarations
for functions defined in an external C library following the
line `extern (C) @nogc nothrow:`. Here are some examples of
such
On Friday, 12 April 2024 at 03:57:40 UTC, John Dougan wrote:
What is the procedure for bug reporting? I'm looking at the
issues tracker and have no clue how to drive the search to see
if this is already there.
https://issues.dlang.org
While entering the bug title, it does a fuzzy search
On Thursday, 11 April 2024 at 15:00:49 UTC, Steven Schveighoffer
wrote:
So D can provide a nice mechanism to show what is happening --
`pragma(msg, ...)`
If I do that with the two types above I see something *very*
interesting:
```d
pragma(msg, FnPrefixT);
pragma(msg, FnSuffixT);
```
```
On Tuesday, 9 April 2024 at 12:45:55 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 09/04/2024 12:48 PM, Liam McGillivray wrote:
I suppose this was a good new thing to learn, though I'm still
quite far from being able to construct a function from another
function using a template.
I
On Thursday, 11 April 2024 at 14:54:36 UTC, Steven Schveighoffer
wrote:
For a repeatable comparison, you should provide the code which
does 1MB reads.
With pleasure:
import std.stdio : writeln, File, stderr;
const uint BUFSIZE = 1024*1024;
private uint
countnl(File f)
{
uint res = 0;
On Thursday, 11 April 2024 at 03:17:36 UTC, John Dougan wrote:
Interesting. Thank you to both of you.
On Wednesday, 10 April 2024 at 17:38:21 UTC, Steven
Schveighoffer wrote:
On Wednesday, 10 April 2024 at 11:34:06 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Place your attributes on the
On Thursday, 11 April 2024 at 00:24:44 UTC, Andy Valencia wrote:
I wrote a "count newlines" based on mapped files. It used
about twice the CPU of the version which just read 1 meg at a
time. I thought something was amiss (needless slice
indirection or something), so I wrote the code in C.
Interesting. Thank you to both of you.
On Wednesday, 10 April 2024 at 17:38:21 UTC, Steven Schveighoffer
wrote:
On Wednesday, 10 April 2024 at 11:34:06 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Place your attributes on the right hand side of the function,
not the left side.
Use the left
On Wednesday, April 10, 2024 2:41:56 PM MDT Lettever via Digitalmars-d-learn
wrote:
> ```
> import std;
>
> Nullable!int func() => 3;
> void main() {
> Nullable!int a = 3;
> //works fine
> Nullable!int b = func();
> //does not compile
> }
Te
I wrote a "count newlines" based on mapped files. It used about
twice the CPU of the version which just read 1 meg at a time. I
thought something was amiss (needless slice indirection or
something), so I wrote the code in C. It had the same CPU usage
as the D version. So...mapped files,
On Wednesday, 10 April 2024 at 21:38:22 UTC, Andy Valencia wrote:
On Wednesday, 10 April 2024 at 20:41:56 UTC, Lettever wrote:
```
import std;
Nullable!int func() => 3;
void main() {
Nullable!int a = 3;
//works fine
Nullable!int b = func();
//does not compile
}
Why make
On Wednesday, 10 April 2024 at 20:41:56 UTC, Lettever wrote:
```
import std;
Nullable!int func() => 3;
void main() {
Nullable!int a = 3;
//works fine
Nullable!int b = func();
//does not compile
}
Why make func() Nullable? It just wants to give you an int,
right? Making it a
```c
void SDL_GetVersion(SDL_version * ver);
```
It doesn't return anything.
Its return type is void.
See the argument list where it lists the types of the arguments:
``template writeln is not callable using argument types !()(string, void)``
Which aligns with the arguments you passed to
import bindbc.sdl;
import bindbc.loader;
SDL_version ver;
SDL_GetVersion();
writeln("version = ", ver); // runs and displays: version =
SDL_version(2, 30, 2)
writeln("version = ", SDL_GetVersion()); // compile fails
with
// template `writeln`
On Tuesday, 9 April 2024 at 23:50:36 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 10/04/2024 11:21 AM, Liam McGillivray wrote:
On Sunday, 7 April 2024 at 08:59:55 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Unfortunately runtime and CTFE are the same target in the
compiler.
So that
On Wednesday, 10 April 2024 at 11:34:06 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Place your attributes on the right hand side of the function,
not the left side.
Use the left side for attributes/type qualifiers that go on the
return type.
Just a word of warning, this explanation
Place your attributes on the right hand side of the function, not the
left side.
Use the left side for attributes/type qualifiers that go on the return type.
```d
bool[7] stagesToProcess = false;
bool shouldDoInStages(int index) @nogc nothrow @safe
{
return stagesToProcess[index];
}
On 10/04/2024 2:50 PM, Liam McGillivray wrote:
On Tuesday, 9 April 2024 at 23:50:36 UTC, Richard (Rikki) Andrew
Cattermole wrote:
The string mixin triggers CTFE, if ``EnumPrefixes`` wasn't templated,
that would cause codegen and hence error. If you called it in a
context that wasn't CTFE only,
Below is a example program that illustrates my issue.
When compiled at run.dlang I get:
```
onlineapp.d(18): Error: `@safe` function
`onlineapp.processSafely!(1, 4).processSafely` cannot call
`@system` function pointer `shouldDo`
onlineapp.d(28): Error: template instance
On Tuesday, 9 April 2024 at 23:50:36 UTC, Richard (Rikki) Andrew
Cattermole wrote:
The string mixin triggers CTFE, if ``EnumPrefixes`` wasn't
templated, that would cause codegen and hence error. If you
called it in a context that wasn't CTFE only, it would codegen
even with template and would
On 10/04/2024 11:21 AM, Liam McGillivray wrote:
On Sunday, 7 April 2024 at 08:59:55 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Unfortunately runtime and CTFE are the same target in the compiler.
So that function is being used for both, and hence uses GC (appending).
Are you sure that
On Sunday, 7 April 2024 at 08:59:55 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Unfortunately runtime and CTFE are the same target in the
compiler.
So that function is being used for both, and hence uses GC
(appending).
Are you sure that string appending was really the problem that
On 09/04/2024 12:48 PM, Liam McGillivray wrote:
On Tuesday, 9 April 2024 at 00:02:02 UTC, Richard (Rikki) Andrew
Cattermole wrote:
```d
enum Value = (a, b) {
return a + b;
}(1, 2);
```
This alone should be a CTFE only function.
But if we want template parameters, we'd need to wrap it
Practical example: some framework allows it's user to define
types of some messages. It can be done by manual calls like
`something.registerMessage!T1()`,
`something.registerMessage!T2()`. Other way is to leave it to
framework: just annotate `T1`, `T2` with `@Command` UDA and call
some core
On Sunday, 7 April 2024 at 06:46:39 UTC, Liam McGillivray wrote:
instantiated from here: `front!char`
Looks like autodecoding, try to comment `canFind`.
On Tuesday, 9 April 2024 at 00:02:02 UTC, Richard (Rikki) Andrew
Cattermole wrote:
```d
enum Value = (a, b) {
return a + b;
}(1, 2);
```
This alone should be a CTFE only function.
But if we want template parameters, we'd need to wrap it with
the template.
```d
template Value(int a,
On 09/04/2024 11:42 AM, Liam McGillivray wrote:
On Monday, 8 April 2024 at 08:12:22 UTC, Richard (Rikki) Andrew
Cattermole wrote:
```d
template Foo(Args) {
enum Foo = () {
return Args.init;
}();
}
```
Something like that should work instead.
I'm sorry, but I can't
On Monday, 8 April 2024 at 08:12:22 UTC, Richard (Rikki) Andrew
Cattermole wrote:
```d
template Foo(Args) {
enum Foo = () {
return Args.init;
}();
}
```
Something like that should work instead.
I'm sorry, but I can't comprehend any of your example. What
would be fed into
On Monday, 8 April 2024 at 13:23:12 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 09/04/2024 1:20 AM, Dmitry Olshansky wrote:
I haven’t done any research on the subject, would be nice if
somebody pointed me to good example of how it’s done.
—
Dmitry Olshansky
CEO @ Glowlabs
On 09/04/2024 1:20 AM, Dmitry Olshansky wrote:
I haven’t done any research on the subject, would be nice if somebody
pointed me to good example of how it’s done.
—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me
In case you haven't already found:
I haven’t done any research on the subject, would be nice if
somebody pointed me to good example of how it’s done.
—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me
On Thursday, 4 April 2024 at 18:14:54 UTC, BoQsc wrote:
I'm looking for more readable standard function to add a
**character** literal to a **string**.
Concatenate is the verb you're looking for, not add. 'Adding' a
`char` to a `string` sounds like you want `myString[] +=
myChar;`, which
On Monday, 8 April 2024 at 07:53:01 UTC, Dom DiSc wrote:
On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
Try `debug unittest {...}`?
Cool. This seems to work. That's a nice workaroud for tests.
Yay!
Nice, fyi, you can use it with statements inside function bodies
as well.
On 08/04/2024 10:45 AM, Liam McGillivray wrote:
On Sunday, 7 April 2024 at 08:59:55 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Unfortunately runtime and CTFE are the same target in the compiler.
:-(
Will this ever be changed?
A tad unlikely, it would be a rather large change
On Monday, 8 April 2024 at 07:03:40 UTC, Alexandru Ermicioi wrote:
On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
I'm creating a library that is completely pure, but it doesn't
compile with pure: at the top because of one impure unittest
(which uses random to test some things only
On Sunday, 7 April 2024 at 23:32:24 UTC, MrJay wrote:
A better way to apply a attribute to an entire file is to use
an explicit scope you can still apply this to basically the
entire file but leave the tests out of it.
Better than an explicit impure (or pure=false) attribute?
I don't think
On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
I'm creating a library that is completely pure, but it doesn't
compile with pure: at the top because of one impure unittest
(which uses random to test some things only probabilistic)!
So do I really need to declare every function pure
On Sunday, 24 March 2024 at 07:41:41 UTC, Dom DiSc wrote:
I'm creating a library that is completely pure, but it doesn't
compile with pure: at the top because of one impure unittest
(which uses random to test some things only probabilistic)!
So do I really need to declare every function pure
On Sunday, 7 April 2024 at 08:59:55 UTC, Richard (Rikki) Andrew
Cattermole wrote:
Unfortunately runtime and CTFE are the same target in the
compiler.
:-(
Will this ever be changed?
```d
template Foo(Args) {
enum Foo = () {
return Args.init;
}();
}
```
Unfortunately runtime and CTFE are the same target in the compiler.
So that function is being used for both, and hence uses GC (appending).
```d
template Foo(Args) {
enum Foo = () {
return Args.init;
}();
}
```
Something like that should work instead.
I'm making a modification to a D binding for a C library. I made
a CTFE function which takes a function declaration with one or
more `const(char)*` or `char*` parameters and makes an overload
that accepts D strings. While this function is only used during
compile time, unfortunately, I have
On Wednesday, 3 April 2024 at 21:57:00 UTC, Liam McGillivray
wrote:
Alright. I suppose that some of the optimization decisions I
have made so far may have resulted in less readable code for
little performance benefit. Now I'm trying to worry less about
optimization. Everything has been very
On Wed, Apr 03, 2024 at 09:57:00PM +, Liam McGillivray via
Digitalmars-d-learn wrote:
> On Friday, 29 March 2024 at 01:18:22 UTC, H. S. Teoh wrote:
> > Take a look at the docs for core.memory.GC. There *is* a method
> > GC.free that you can use to manually deallocate GC-a
On Saturday, 6 April 2024 at 12:05:56 UTC, Jonathan M Davis wrote:
Actually, since I'm usually the one who does the FreeBSD ones
anyway, here you go:
https://github.com/dlang/dmd/pull/16359
The declarations compile, and they should match the ones in C,
since I copied them over and then
Actually, since I'm usually the one who does the FreeBSD ones anyway, here
you go:
https://github.com/dlang/dmd/pull/16359
The declarations compile, and they should match the ones in C, since I
copied them over and then tweaked them, but I haven't actually tested them.
All that being said, even
On Saturday, April 6, 2024 3:57:46 AM MDT Arjan via Digitalmars-d-learn wrote:
> I'm using posix mqueue in a D application on Linux. Works fine.
> But on FreeBSD it fails to compile due to the version statement:
>
> [version (CRuntime_Glibc):](
> https://github.com
On Saturday, 6 April 2024 at 09:21:34 UTC, rkompass wrote:
I checked:
```d
import std.stdio,
std.range,
std.algorithm;
struct N(T)
{
T last, step, first;
bool empty() => first >= last;
T front() => first;
auto popFront() => first += step;
}
void main() {
auto r1 =
On Friday, 5 April 2024 at 21:26:10 UTC, Salih Dincer wrote:
On Friday, 5 April 2024 at 21:16:42 UTC, rkompass wrote:
In the first example the int's are converted to doubles (also
common type).
But they appear as int's because writeln does not write a
trailing .0.
But it doesn't work as
On Friday, April 5, 2024 3:11:42 AM MDT Dom DiSc via Digitalmars-d-learn
wrote:
> On Sunday, 24 March 2024 at 09:16:20 UTC, Jonathan M Davis wrote:
> > So, yes, you've run into a problem that it would be nice to
> > have a better fix for, but even if we could negate attributes
On Friday, 5 April 2024 at 14:41:12 UTC, Carl Sturtivant wrote:
On Friday, 5 April 2024 at 07:37:20 UTC, Paolo Invernizzi wrote:
pragma(msg, x) ?
No.
`__ctfeWrite(x)` is executed inside an executing function like
any other statement in it, and can have an argument `x`
computed during that
On Friday, 5 April 2024 at 21:16:42 UTC, rkompass wrote:
In the first example the int's are converted to doubles (also
common type).
But they appear as int's because writeln does not write a
trailing .0.
But it doesn't work as you say! I even tried it on an older
version and got the same
On Friday, 5 April 2024 at 16:05:20 UTC, H. S. Teoh wrote:
On Fri, Apr 05, 2024 at 03:18:09PM +, Salih Dincer via
Digitalmars-d-learn wrote:
Hi everyone,
Technically r1 and r2 are different types of range. Isn't it
inconsistent to chain both? If not, why is the char type
converted to int
On Friday, 5 April 2024 at 16:05:20 UTC, H. S. Teoh wrote:
On Fri, Apr 05, 2024 at 03:18:09PM +, Salih Dincer via
Digitalmars-d-learn wrote:
Hi everyone,
Technically r1 and r2 are different types of range. Isn't it
inconsistent to chain both? If not, why is the char type
converted to int
On Fri, Apr 05, 2024 at 03:18:09PM +, Salih Dincer via Digitalmars-d-learn
wrote:
> Hi everyone,
>
> Technically r1 and r2 are different types of range. Isn't it
> inconsistent to chain both? If not, why is the char type converted to
> int?
[...]
It's not inconsistent
Hi everyone,
Technically r1 and r2 are different types of range. Isn't it
inconsistent to chain both? If not, why is the char type
converted to int?
```d
import std.stdio,
std.range;
void main() {
auto r1 = N!size_t(10, 1, 1);
auto r2 = N!real(15, .5, 10);
On Friday, 5 April 2024 at 07:37:20 UTC, Paolo Invernizzi wrote:
pragma(msg, x) ?
No.
`__ctfeWrite(x)` is executed inside an executing function like
any other statement in it, and can have an argument `x` computed
during that execution.
It is defined to output the computed text `x` to
On Thursday, 4 April 2024 at 14:29:56 UTC, WhatMeWorry wrote:
Error: Unresolvable dependencies to package bindbc-loader:
bindbc-opengl 0.13.0 depends on bindbc-loader ~>0.3.0
bindbc-sdl 1.4.7 depends on bindbc-loader ~>1.1.0
Please update `bindbc-opengl` to `1.1.0`. I think it's
On Sunday, 24 March 2024 at 09:16:20 UTC, Jonathan M Davis wrote:
So, yes, you've run into a problem that it would be nice to
have a better fix for, but even if we could negate attributes
in general, there are good reasons to prefer to avoid
mass-applying attributes.
I don't see it as
On Thursday, 4 April 2024 at 15:43:55 UTC, Carl Sturtivant wrote:
On Thursday, 4 April 2024 at 15:07:21 UTC, Richard (Rikki)
Andrew Cattermole wrote:
Ah yes, I forgot about that particular thing, doesn't see much
use as far as I'm aware.
It should be working though.
```D
enum X =
On Thursday, 4 April 2024 at 21:23:00 UTC, user1234 wrote:
On Thursday, 4 April 2024 at 19:56:50 UTC, Ferhat Kurtulmuş
wrote:
[...]
```d
module runnable;
import std.stdio : writeln;
import std.range : chain;
void main() @nogc
{
auto s = chain("as ", "df ", "j"); // s is lazy
On Thursday, 4 April 2024 at 19:56:50 UTC, Ferhat Kurtulmuş wrote:
My favorite d feature is lazy ranges. No allocation here.
```d
auto s = chain("as ", "df ", "j"); // s is lazy
writeln(s);
```
```d
import std.range : chain;
void main()
{
string word = "hello";
auto noError = chain(word,
201 - 300 of 76602 matches
Mail list logo
