On Thursday, 10 June 2021 at 15:19:27 UTC, kinke wrote:
Confirmed: https://issues.dlang.org/show_bug.cgi?id=22014
Thank you for the bug report. I'm glad I couldn't handle it
myself.
The only thing that bothers me is that there is no sign of this
problem being fixed.
I fear that this may be
STR:
1. open
http://forum.dlang.org/static-bundle/637528586548394375/dlang.org/js/dlang.js+js/dfeed.js
2. press reload (F5 or ctrl+R)
On Tuesday, 15 June 2021 at 06:39:24 UTC, seany wrote:
...
This is the best I could do: https://run.dlang.io/is/dm8LBP
For some reason, LDC refuses to vectorize or even just unroll the
nonparallel version, and more than one `parallel` corrupts the
results.
But judging by the results you expec
On Tuesday, 15 June 2021 at 12:39:40 UTC, Dennis wrote:
On Tuesday, 15 June 2021 at 12:18:26 UTC, VitaliiY wrote:
[...]
```D
enum string ADDBITS(string a, string b) = `
{
bitbuffer = (bitbuffer<<(`~a~`))|((`~b~`)&((1<<`~a~`)-1));
numbits += (`~a~`);
mixin(STOREBITS);
}`;
// on use:
On Tuesday, 15 June 2021 at 12:38:15 UTC, Ali Çehreli wrote:
On 6/15/21 5:18 AM, VitaliiY wrote:
> STOREBITS and ADDBITS use variables defined in STARTDATA
If possible in your use case, I would put those variables in a
struct type and make add() a member function. However, a
similar type alre
On Sunday, 13 June 2021 at 21:13:33 UTC, frame wrote:
On Sunday, 13 June 2021 at 10:02:45 UTC, cc wrote:
it seems to work as expected with the same C# code. Does D
explicitly disallow slices as an extern(C) export parameter
type?
The spec says that there is no equivalent to type[]. You get
On 6/15/21 12:24 AM, surlymoor wrote:
All my custom range types perform all their meaningful work in their
respective popFront methods, in addition to its expected source data
iteration duties. The reason I do this is because I swear I read in a
github discussion that front is expected to be O(
On Tuesday, 15 June 2021 at 09:09:29 UTC, Ali Çehreli wrote:
On 6/14/21 11:39 PM, seany wrote:
> [...]
I gave an example of it in my DConf Online 2020 presentation as
well:
https://www.youtube.com/watch?v=dRORNQIB2wA&t=1324s
> [...]
That is violating a pa
On Tue, Jun 15, 2021 at 02:20:11PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
> It's a time-space tradeoff. As you say, caching requires additional
> space to store the cached element. On the other hand, *not* caching
> means that you spend unnecessary time computing the next element
On Tuesday, 15 June 2021 at 04:24:09 UTC, surlymoor wrote:
All my custom range types perform all their meaningful work in
their respective popFront methods, in addition to its expected
source data iteration duties. The reason I do this is because I
swear I read in a github discussion that front
On 6/14/21 10:17 PM, mw wrote:
> I think there is another convention (although it's not formally
> enforced, but should be) is:
>
> -- `obj.front() [should be] const`, i.e. it shouldn't modify `obj`, so
> can be called multiple times at any given state, and produce the same
> result
In other wor
On Tuesday, 15 June 2021 at 12:18:26 UTC, VitaliiY wrote:
It's simple with STARTDATA as mixin, but STOREBITS and ADDBITS
use variables defined in STARTDATA scope, so I can't understand
how to do mixin template with it.
If the code duplication isn't too bad, consider just expanding
the C macro
On 6/15/21 5:18 AM, VitaliiY wrote:
> STOREBITS and ADDBITS use variables defined in STARTDATA
If possible in your use case, I would put those variables in a struct
type and make add() a member function. However, a similar type already
exists as std.bitmanip.BitArray.
Ali
Could anybody help with translation of this C macro to D
mixin/mixin template? Here a - unsigned char, b - int. It's
simple with STARTDATA as mixin, but STOREBITS and ADDBITS use
variables defined in STARTDATA scope, so I can't understand how
to do mixin template with it.
#define STARTDAT
On 6/14/21 11:39 PM, seany wrote:
> I know that D has parallel foreach [like
> this](http://ddili.org/ders/d.en/parallelism.html).
I gave an example of it in my DConf Online 2020 presentation as well:
https://www.youtube.com/watch?v=dRORNQIB2wA&t=1324s
> int[] c ;
>
On Monday, 14 June 2021 at 17:34:00 UTC, Steven Schveighoffer
wrote:
D doesn't have head-const. So you must hide the mutable
implementation to get this to work.
You'd want to do this anyway, since you don't want to directly
use the pointer for anything like indexing (it should first
validate
On Tuesday, 15 June 2021 at 07:41:06 UTC, jfondren wrote:
On Tuesday, 15 June 2021 at 06:39:24 UTC, seany wrote:
[...]
add a `writeln(c.length);` in your inner loop and consider
the output. If you were always pushing to the end of c, then
only unique numbers should be output. But I see e.g. si
On Tuesday, 15 June 2021 at 06:39:24 UTC, seany wrote:
What am I doing wrong?
add a `writeln(c.length);` in your inner loop and consider
the output. If you were always pushing to the end of c, then
only unique numbers should be output. But I see e.g. six
occurrences of 0, four of 8 ...
Here's
18 matches
Mail list logo