On Wednesday, 20 July 2016 at 16:44:11 UTC, ketmar wrote:
On Wednesday, 20 July 2016 at 13:33:34 UTC, Mike Parker wrote:
There is no auto-decoding going on here,
...
as char[] and wchar[] are rejected outright since they are not
considered random access ranges.
...due to autodecoding.
No,
On Wednesday, July 20, 2016 18:08:14 stunaep via Digitalmars-d-learn wrote:
> On Wednesday, 20 July 2016 at 05:45:21 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, July 20, 2016 04:03:23 stunaep via
> >
> > Digitalmars-d-learn wrote:
> >> [...]
> >
> > If you want the list of members in an
On 07/19/2016 08:55 AM, Rufus Smith wrote:
I have some functions that take other functions. I would like the
attributes to be able to "fall" through so I get overload like behavior.
I only care that I am passing a function, not if it is shared,
extern(C), pure, @nogc, etc.
void foo(R, A...)(R
On Wednesday, 20 July 2016 at 18:08:14 UTC, stunaep wrote:
On Wednesday, 20 July 2016 at 05:45:21 UTC, Jonathan M Davis
wrote:
On Wednesday, July 20, 2016 04:03:23 stunaep via
Digitalmars-d-learn wrote:
[...]
If you want the list of members in an enum, then use
std.traits.EnumMembers and
On Wednesday, 20 July 2016 at 16:03:27 UTC, pineapple wrote:
On Wednesday, 20 July 2016 at 13:33:34 UTC, Mike Parker wrote:
There is no auto-decoding going on here, as char[] and wchar[]
are rejected outright since they are not considered random
access ranges.
They are considered random
On 07/19/2016 09:03 PM, stunaep wrote:
> And why on earth are different enum items with the same values
> equal to each other?
I've seen code where it made sense. Searching for an example reveals:
enum Scope
{
Transient,
Singleton,
Default=Transient
}
> Seems to me like there's no
On Wednesday, 20 July 2016 at 05:45:21 UTC, Jonathan M Davis
wrote:
On Wednesday, July 20, 2016 04:03:23 stunaep via
Digitalmars-d-learn wrote:
[...]
If you want the list of members in an enum, then use
std.traits.EnumMembers and you'll get a compile-time list of
them. It can be made into a
On 07/20/2016 10:40 AM, Jack Stouffer wrote:
On Wednesday, 20 July 2016 at 17:31:18 UTC, Ali Çehreli wrote:
making it impossible to access randomly
making it impossible to access randomly __correctly__, unless you're
safely assuming there's only ASCII in your string.
Yes, perhaps I should
On Tuesday, 19 July 2016 at 20:19:53 UTC, WhatMeWorry wrote:
On Sunday, 17 July 2016 at 05:57:52 UTC, WhatMeWorry wrote:
I don't suppose there's a way to "see" source code generated
by templates after a compile but before execution? Or does
the compiler generate it to a lower level on the
On Wednesday, 20 July 2016 at 17:31:18 UTC, Ali Çehreli wrote:
making it impossible to access randomly
making it impossible to access randomly __correctly__, unless
you're safely assuming there's only ASCII in your string.
On Wednesday, 20 July 2016 at 17:31:18 UTC, Ali Çehreli wrote:
I think both not being random access ranges and there is
auto-decoding in Phobos are design decisions due to the fact
that char[] is a multi-byte encoding.
Phobos could choose not to auto-decode but char[] would still
be
On 07/20/2016 09:44 AM, ketmar wrote:
On Wednesday, 20 July 2016 at 13:33:34 UTC, Mike Parker wrote:
There is no auto-decoding going on here,
...
as char[] and wchar[] are rejected outright since they are not
considered random access ranges.
...due to autodecoding.
I think both not being
On 07/20/2016 06:18 PM, Mike Parker wrote:
The relevant lines I quoted from the docs above explain quite clearly
that it's because they are multi-byte formats. Indexing them is not
inefficient, it simply makes no sense. What does it mean to take the
value at index i when it is part of a
On Wednesday, 20 July 2016 at 13:33:34 UTC, Mike Parker wrote:
There is no auto-decoding going on here,
...
as char[] and wchar[] are rejected outright since they are not
considered random access ranges.
...due to autodecoding.
On Wednesday, 20 July 2016 at 16:08:26 UTC, pineapple wrote:
Pardon my being scatterbrained (and there not being an "edit
post" function) - you're referring to phobos not considering
char[] and wchar[] to have random access? The reason they are
not considered to have random access is
So I'm trying to build druntime correctly, I corrected some
problems here and there, but I still cannot link with
libdruntime-ldc.a:
/opt/arm-2009q1/bin/arm-none-linux-gnueabi-gcc loire.o
lib/libdruntime-ldc.a -o loire
I get many errors like:
On Wednesday, 20 July 2016 at 16:04:50 UTC, pineapple wrote:
On Wednesday, 20 July 2016 at 16:03:27 UTC, pineapple wrote:
On Wednesday, 20 July 2016 at 13:33:34 UTC, Mike Parker wrote:
There is no auto-decoding going on here, as char[] and
wchar[] are rejected outright since they are not
On Wednesday, 20 July 2016 at 16:03:27 UTC, pineapple wrote:
On Wednesday, 20 July 2016 at 13:33:34 UTC, Mike Parker wrote:
There is no auto-decoding going on here, as char[] and wchar[]
are rejected outright since they are not considered random
access ranges.
They are considered random
On Wednesday, 20 July 2016 at 13:33:34 UTC, Mike Parker wrote:
There is no auto-decoding going on here, as char[] and wchar[]
are rejected outright since they are not considered random
access ranges.
They are considered random access ranges by my ranges library,
because they are treated as
On Wednesday, 20 July 2016 at 15:40:16 UTC, Lobelia Noakes wrote:
On Sunday, 17 July 2016 at 01:58:59 UTC, pineapple wrote:
On Sunday, 17 July 2016 at 01:57:21 UTC, pineapple wrote:
On Saturday, 16 July 2016 at 22:05:49 UTC, ketmar wrote:
actually, `foreach (v; rng)` looks like `foreach` is
On Sunday, 17 July 2016 at 01:58:59 UTC, pineapple wrote:
On Sunday, 17 July 2016 at 01:57:21 UTC, pineapple wrote:
On Saturday, 16 July 2016 at 22:05:49 UTC, ketmar wrote:
actually, `foreach (v; rng)` looks like `foreach` is
*reusing* *existing* *variable*. most of the time you can put
On Wednesday, 20 July 2016 at 10:40:04 UTC, pineapple wrote:
There's also the shuffle module in mach.range which doesn't do
any auto-decoding:
https://github.com/pineapplemachine/mach.d/blob/master/mach/range/random/shuffle.d
Interesting project. Thanks for the link.
On Wednesday, 20 July 2016 at 10:40:04 UTC, pineapple wrote:
On Wednesday, 20 July 2016 at 08:02:07 UTC, Mike Parker wrote:
You can then go to the documentation for
std.range.primitives.isRandomAccessRange [2], where you'll
find the following:
"Although char[] and wchar[] (as well as their
I think my cross-compile LDC is fine.
I tried to build this D program:
/// loire.d
int main()
{
return 42;
}
However, the run-time is not (neither is phobos), most of the
linker issues come from the druntime. So...
I wrote my own druntime. Here's the code:
/// dummyruntime.d
// from
On Wednesday, 20 July 2016 at 08:02:07 UTC, Mike Parker wrote:
You can then go to the documentation for
std.range.primitives.isRandomAccessRange [2], where you'll find
the following:
"Although char[] and wchar[] (as well as their qualified
versions including string and wstring) are arrays,
On Wednesday, 20 July 2016 at 08:30:37 UTC, Mike Parker wrote:
representation does not allocate any new memory. It points to
the same memory, same data. If we think of D arrays as
something like this:
struct Array(T) {
size_t len;
T* ptr;
}
Then representation is doing this:
On Wednesday, 20 July 2016 at 08:01:01 UTC, Lodovico Giaretta
wrote:
Note that void is a type, while S is not. So you can do:
assert(is(void)) // is(type) returns true
assert(!is(S)) // is(template) returns false;
Thanks very much. I should have noticed this before. T.T
On Wednesday, 20 July 2016 at 08:18:55 UTC, celavek wrote:
As far as my current understanding goes the shuffle will be
done in place.
If I use the "representation" would that still hold, that is
will I be able
to use the same char[] but in the shuffled form? (of course I
will test that)
On Wednesday, 20 July 2016 at 08:02:07 UTC, Mike Parker wrote:
If you are absolutely, 100% certain that you are dealing with
ASCII, you can do this:
```
import std.string : representation;
randomShuffle(charArray.representation);
That will give you a ubyte[] for char[] and a ushort[] for
On Wednesday, 20 July 2016 at 08:05:20 UTC, Mike Parker wrote:
On Wednesday, 20 July 2016 at 08:02:07 UTC, Mike Parker wrote:
On Wednesday, 20 July 2016 at 07:49:38 UTC, celavek wrote:
If you are absolutely, 100% certain that you are dealing with
ASCII, you can do this:
And I forgot to
On Wednesday, 20 July 2016 at 08:02:07 UTC, Mike Parker wrote:
On Wednesday, 20 July 2016 at 07:49:38 UTC, celavek wrote:
If you are absolutely, 100% certain that you are dealing with
ASCII, you can do this:
And I forgot to add:
Otherwise, you'll want to convert to dchar[] (probably via
On Wednesday, 20 July 2016 at 07:49:38 UTC, celavek wrote:
I thought that I could use a dynamic array as a range ...
You can. However, if you take a look at the documentation for
std.random.randomShuffle [1], you'll find the following
constraint:
if (isRandomAccessRange!Range);
You can
On Wednesday, 20 July 2016 at 05:54:41 UTC, mogu wrote:
On Wednesday, 20 July 2016 at 01:50:37 UTC, Adam D. Ruppe wrote:
On Wednesday, 20 July 2016 at 01:14:05 UTC, mogu wrote:
Why S's type isn't something like `S: (T) -> S`?
Because S isn't a type... think of a template as being like a
Hi
I'm trying to shuffle a character array but I get some
compilation errors.
*
char[] upper = std.ascii.uppercase.dup;
randomShuffle!(typeof(upper))(upper);
randomShuffle(upper);
example.d(34): Error: template std.random.randomShuffle cannot
deduce function from argument types
34 matches
Mail list logo
