I used to not even notice that if D declare an array in C-style,
and then indexing it will also in C-style :)
Actually, I have a small question. And what is the advantage of
indexing arrays D-style in front of a C-style arrays? Because
C-style indexing is much more familiar: first, we point line
On 6/2/15 9:43 PM, Mike Parker wrote:
On 6/3/2015 1:37 AM, Paul wrote:
On Tuesday, 2 June 2015 at 16:23:32 UTC, Adam D. Ruppe wrote:
On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:
CoOrd[NumPaths][] pathList;
Try CoOrd[][NumPaths].
The order is opposite in D style than in C style (I th
On 6/3/2015 1:37 AM, Paul wrote:
On Tuesday, 2 June 2015 at 16:23:32 UTC, Adam D. Ruppe wrote:
On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:
CoOrd[NumPaths][] pathList;
Try CoOrd[][NumPaths].
The order is opposite in D style than in C style (I thnk the D style
makes more sense, it jus
On Tuesday, 2 June 2015 at 22:36:36 UTC, Steven Schveighoffer
wrote:
On 6/2/15 5:42 PM, anonymous wrote:
On Tuesday, 2 June 2015 at 20:56:41 UTC, Steven Schveighoffer
wrote:
Hm... I think the issue might possibly be solved. What
version of the
compiler are you using?
I think 14005 (and 14578
On 6/2/15 5:42 PM, anonymous wrote:
On Tuesday, 2 June 2015 at 20:56:41 UTC, Steven Schveighoffer wrote:
Hm... I think the issue might possibly be solved. What version of the
compiler are you using?
I think 14005 (and 14578) are fixed in git head, because there's no
assumeSafeAppend in byLine
On Tuesday, 2 June 2015 at 21:43:45 UTC, Stiff wrote:
So...in the meantime, I'll just pad my input I guess?
It's a mess and I'm not sure what works and what doesn't, but
here are some options:
byLineCopy: Could be fine as it doesn't reuse any buffers.
readln without passing a buffer: as abo
On Tuesday, 2 June 2015 at 21:35:54 UTC, Steven Schveighoffer
wrote:
OK. I can reproduce now with all 3 test cases. I tweaked the
line sizes a little bit. Noting that it fails on 2.067.0 and
2.067.1 on Linux x64, but passes just fine on OSX same versions.
FWIW, you don't need anything except
On Tuesday, 2 June 2015 at 20:56:41 UTC, Steven Schveighoffer
wrote:
Hm... I think the issue might possibly be solved. What version
of the compiler are you using?
I think 14005 (and 14578) are fixed in git head, because there's
no assumeSafeAppend in byLine anymore.
But the underlying issue
On 06/02/2015 01:16 PM, "Per =?UTF-8?B?Tm9yZGzDtnci?=
" wrote:
Is there some elegant way of creating "isolated" types in D similar to
the semantics of `subtype` in Ada.
Something like this
struct A
{
this(int value) { this._value = value; }
private int _value;
alias _value this;
On 06/02/2015 01:56 PM, Steven Schveighoffer wrote:
On 6/2/15 4:43 PM, Steven Schveighoffer wrote:
On 6/2/15 3:35 PM, anonymous wrote:
It's an embarrassing issue that comes up again and again. I really hope
a fix makes it through soon.
https://issues.dlang.org/show_bug.cgi?id=14005
I can re
On 6/2/15 5:22 PM, Stiff wrote:
On Tuesday, 2 June 2015 at 21:15:19 UTC, Stiff wrote:
On Tuesday, 2 June 2015 at 21:10:20 UTC, Stiff wrote:
I'm on dmd v2.067 (according to dmd --version), using Arch Linux
kernel version 4.0.4-2. I installed dmd from the Arch community repo
just a couple days ag
On Tuesday, 2 June 2015 at 21:15:19 UTC, Stiff wrote:
On Tuesday, 2 June 2015 at 21:10:20 UTC, Stiff wrote:
On Tuesday, 2 June 2015 at 20:56:41 UTC, Steven Schveighoffer
wrote:
On 6/2/15 4:43 PM, Steven Schveighoffer wrote:
On 6/2/15 3:35 PM, anonymous wrote:
It's an embarrassing issue that c
On Tuesday, 2 June 2015 at 21:10:20 UTC, Stiff wrote:
On Tuesday, 2 June 2015 at 20:56:41 UTC, Steven Schveighoffer
wrote:
On 6/2/15 4:43 PM, Steven Schveighoffer wrote:
On 6/2/15 3:35 PM, anonymous wrote:
It's an embarrassing issue that comes up again and again. I
really hope
a fix makes it
On Tuesday, 2 June 2015 at 20:56:41 UTC, Steven Schveighoffer
wrote:
On 6/2/15 4:43 PM, Steven Schveighoffer wrote:
On 6/2/15 3:35 PM, anonymous wrote:
It's an embarrassing issue that comes up again and again. I
really hope
a fix makes it through soon.
https://issues.dlang.org/show_bug.cgi?i
On 6/2/15 4:43 PM, Steven Schveighoffer wrote:
On 6/2/15 3:35 PM, anonymous wrote:
It's an embarrassing issue that comes up again and again. I really hope
a fix makes it through soon.
https://issues.dlang.org/show_bug.cgi?id=14005
I can reproduce this one. I'll figure this out.
Hm... I thi
On 6/2/15 3:35 PM, anonymous wrote:
It's an embarrassing issue that comes up again and again. I really hope
a fix makes it through soon.
https://issues.dlang.org/show_bug.cgi?id=14005
I can reproduce this one. I'll figure this out.
-Steve
On 6/2/15 4:30 PM, Steven Schveighoffer wrote:
I could not reproduce your error either (on OSX version 2.067.0). What
OS/arch are you using? I'll try it in linux.
Nope, still can't reproduce.
-Steve
On 6/2/15 3:57 PM, Stiff wrote:
Here's the least code I can reproduce it with:
//appropriate imports here
void main(string[] args)
{
auto groupFile = new File(args[1]);
int groupNum = 0;
foreach (groupLine; groupFile.byLine()){
writeln(groupNum);
groupNum++;
Is there some elegant way of creating "isolated" types in D
similar to the semantics of `subtype` in Ada.
Something like this
struct A
{
this(int value) { this._value = value; }
private int _value;
alias _value this;
}
struct B
{
this(int value) { this._value = value; }
pri
On Tuesday, 2 June 2015 at 19:18:15 UTC, Stiff wrote:
iteration through my loop. I'm consistently getting an
InvalidMemoryOperationError on my 2,547th iteration, and based
on console outputs, I'm fairly certain it's coming from the
byLine() method. To be clear, I'm just doing a simple:
I get
On Tuesday, 2 June 2015 at 20:06:12 UTC, Per Nordlöw wrote:
https://github.com/nordlow/justd/blob/master/bylinefast.d
I'm thinking of renaming it to something other than `byLine`
(perhaps `byChunk`) because it's (no longer) limited to reading
"lines". This because the terminator is an arbitra
On Tuesday, 2 June 2015 at 19:35:04 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 19:18:15 UTC, Stiff wrote:
Hi,
I'm reading in a rather large text file (~25Mb) line by line,
where I don't need to hang on to a line for more than one
iteration through my loop. I'm consistently getting an
I just updated the Kernighan-Ritchie allocator, including documentation:
It's not a high performance allocator. Initially I'd implemented it just
for historical perspective and to make sure the allocator API is
expressive enough to do it justice.
However, a simple idea makes it competitive: r
On Tuesday, 2 June 2015 at 19:47:09 UTC, Andrei Alexandrescu
wrote:
I just updated the Kernighan-Ritchie allocator, including
documentation:
Wrong board?
On Tuesday, 2 June 2015 at 19:18:15 UTC, Stiff wrote:
Hi,
I'm reading in a rather large text file (~25Mb) line by line,
where I don't need to hang on to a line for more than one
iteration through my loop. I'm consistently getting an
InvalidMemoryOperationError on my 2,547th iteration, and bas
On Tuesday, 2 June 2015 at 19:18:15 UTC, Stiff wrote:
Hi,
I'm reading in a rather large text file (~25Mb) line by line,
where I don't need to hang on to a line for more than one
iteration through my loop. I'm consistently getting an
InvalidMemoryOperationError on my 2,547th iteration, and bas
Hi,
I'm reading in a rather large text file (~25Mb) line by line,
where I don't need to hang on to a line for more than one
iteration through my loop. I'm consistently getting an
InvalidMemoryOperationError on my 2,547th iteration, and based on
console outputs, I'm fairly certain it's coming
On 06/02/2015 11:52 AM, rsw0x wrote:
I'm going to read Ali's links and maybe get a better
understanding here.
Also
https://github.com/PhilippeSigaud/D-templates-tutorial
Ali
I have PR for removing this obsolete article and replacing with
more up to date one :
https://github.com/D-Programming-Language/dlang.org/pull/986
On Tuesday, 2 June 2015 at 14:07:20 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 08:10:27 UTC, rsw0x wrote:
exactly what is the difference here?
I have a rather large CTFE-generated TypeTuple in one of my
structs in my project, and I can seemingly replace it with a
Tuple with absolutel
On Tuesday, 2 June 2015 at 18:48:16 UTC, rsw0x wrote:
On Tuesday, 2 June 2015 at 11:49:18 UTC, anonymous wrote:
On Tuesday, 2 June 2015 at 08:10:27 UTC, rsw0x wrote:
The tuple page is even confusing me
http://dlang.org/tuple.html
A variable declared with a TypeTuple becomes an
ExpressionTuple
On Tuesday, 2 June 2015 at 07:18:33 UTC, Robert M. Münch wrote:
On 2015-06-01 17:29:08 +, Steven Schveighoffer said:
No, you must explicitly intialize. Classes are ALL reference
types in D, no in-situ placement of classes
Ok, thanks. Still to much C++ logic in my head ;-) I'm getting
rid
On Tuesday, 2 June 2015 at 11:49:18 UTC, anonymous wrote:
On Tuesday, 2 June 2015 at 08:10:27 UTC, rsw0x wrote:
The tuple page is even confusing me
http://dlang.org/tuple.html
A variable declared with a TypeTuple becomes an
ExpressionTuple:
alias TL = Tuple!(int, long);
is it using Tuple!(T
On Tuesday, 2 June 2015 at 17:03:32 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 16:41:38 UTC, Kyoji Klyden wrote:
src:
string source = readText("test.glvert");
const string sources = source.toStringz;
const int len = source.length;
GLuin
On Tuesday, 2 June 2015 at 16:41:38 UTC, Kyoji Klyden wrote:
src:
string source = readText("test.glvert");
const string sources = source.toStringz;
const int len = source.length;
GLuint vertShader = glCreateShader( GL_VERTEX_SHADER );
On Tuesday, 2 June 2015 at 16:26:30 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 16:23:26 UTC, Kyoji Klyden wrote:
On Tuesday, 2 June 2015 at 15:53:33 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to c
On Tuesday, 2 June 2015 at 16:23:32 UTC, Adam D. Ruppe wrote:
On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:
CoOrd[NumPaths][] pathList;
Try CoOrd[][NumPaths].
The order is opposite in D style than in C style (I thnk the D
style makes more sense, it just reads one direction, but it
do
On Tuesday, 2 June 2015 at 16:22:58 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:
This array of structures...
CoOrd pathList[NumPaths][];
generates a warning when compiled with DMD 32 bit -w flag, but
not 64 bit.
This gives me a warning using rdmd on x64 XUbu
On Tuesday, 2 June 2015 at 16:23:26 UTC, Kyoji Klyden wrote:
On Tuesday, 2 June 2015 at 15:53:33 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
A string is, by definition
On Tuesday, 2 June 2015 at 15:53:33 UTC, Alex Parrill wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
A string is, by definition in D, a character array,
specifically `immutable(char)[]`. It
On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:
This array of structures...
CoOrd pathList[NumPaths][];
generates a warning when compiled with DMD 32 bit -w flag, but
not 64 bit.
This gives me a warning using rdmd on x64 XUbuntu.
If I correct the declaration to 'D style'
CoOrd[NumPat
On Tuesday, 2 June 2015 at 15:53:33 UTC, Alex Parrill wrote:
A string is, by definition in D, a character array,
specifically `immutable(char)[]`. It's not like, for example,
Java in which it's a completely separate type; you can perform
all the standard array operations on strings.
Yes, I be
On Tuesday, 2 June 2015 at 16:17:23 UTC, Paul wrote:
CoOrd[NumPaths][] pathList;
Try CoOrd[][NumPaths].
The order is opposite in D style than in C style (I thnk the D
style makes more sense, it just reads one direction, but it does
index differently than you're used to in C)
This array of structures...
CoOrd pathList[NumPaths][];
generates a warning when compiled with DMD 32 bit -w flag, but
not 64 bit.
If I correct the declaration to 'D style'
CoOrd[NumPaths][] pathList;
It compiles without warning but I cannot append items to the
array like this...
pathLis
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
A string is, by definition in D, a character array, specifically
`immutable(char)[]`. It's not like, for example, Java in which
it's a completely sep
On Tuesday, 2 June 2015 at 15:32:12 UTC, Kyoji Klyden wrote:
On Tuesday, 2 June 2015 at 15:26:50 UTC, Dennis Ritchie wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
string s = "str";
char[]
On Tuesday, 2 June 2015 at 15:26:50 UTC, Dennis Ritchie wrote:
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
string s = "str";
char[] strArr = s.dup;
Thanks! :)
On Tuesday, 2 June 2015 at 15:07:58 UTC, Kyoji Klyden wrote:
quick question: What is the most efficient way to covert a
string to a char array?
string s = "str";
char[] strArr = s.dup;
quick question: What is the most efficient way to covert a string
to a char array?
On Tuesday, 2 June 2015 at 08:10:27 UTC, rsw0x wrote:
exactly what is the difference here?
I have a rather large CTFE-generated TypeTuple in one of my
structs in my project, and I can seemingly replace it with a
Tuple with absolutely zero differences... except I compile
about 60-70% slower.
On Tuesday, 2 June 2015 at 09:34:28 UTC, Ali Çehreli wrote:
On 06/02/2015 01:10 AM, rsw0x wrote:
[...]
The tuple page is even confusing me
http://dlang.org/tuple.html
[...]
Tuple can hold only values, TypeTuple can hold types as well.
Tuple can be created at run time, TypeTuple is a compile
On Tuesday, 2 June 2015 at 08:10:27 UTC, rsw0x wrote:
The tuple page is even confusing me
http://dlang.org/tuple.html
A variable declared with a TypeTuple becomes an ExpressionTuple:
alias TL = Tuple!(int, long);
is it using Tuple!(T...) and TypeTuple!(T...) interchangeably?
Almost.
`Tuple
On Tuesday, 2 June 2015 at 10:04:56 UTC, Jonathan M Davis wrote:
On Tuesday, June 02, 2015 08:57:02 y via Digitalmars-d-learn
wrote:
hi,
is there any reason that the
auto reduce(S, R)(S seed, R r) if (isIterable!R);
parameters are not the other way around?
its kind of not very handy when you d
On 06/02/2015 10:10 AM, rsw0x wrote:
exactly what is the difference here?
I have a rather large CTFE-generated TypeTuple in one of my structs in
my project, and I can seemingly replace it with a Tuple with absolutely
zero differences... except I compile about 60-70% slower.
The tuple page is ev
On Tuesday, June 02, 2015 08:57:02 y via Digitalmars-d-learn wrote:
> hi,
>
> is there any reason that the
> auto reduce(S, R)(S seed, R r) if (isIterable!R);
> parameters are not the other way around?
>
> its kind of not very handy when you do large ufc stuff
Because it predates UFCS.
- Jonathan
On Mon, 01 Jun 2015 21:43:56 -0400, Steven Schveighoffer wrote:
> I don't think a general function such as to with radix is good for this.
> You can probably do better with a custom function, I'm not sure if
> there's any base-64 libraries out there.
std.base64? ;-)
signature.asc
Description: PG
On 06/02/2015 01:10 AM, rsw0x wrote:
exactly what is the difference here?
I have a rather large CTFE-generated TypeTuple in one of my structs in
my project, and I can seemingly replace it with a Tuple with absolutely
zero differences... except I compile about 60-70% slower.
The tuple page is ev
hi,
is there any reason that the
auto reduce(S, R)(S seed, R r) if (isIterable!R);
parameters are not the other way around?
its kind of not very handy when you do large ufc stuff
exactly what is the difference here?
I have a rather large CTFE-generated TypeTuple in one of my
structs in my project, and I can seemingly replace it with a
Tuple with absolutely zero differences... except I compile about
60-70% slower.
The tuple page is even confusing me
http://dlang.org/t
On 2015-06-01 17:29:08 +, Steven Schveighoffer said:
No, you must explicitly intialize. Classes are ALL reference types in
D, no in-situ placement of classes
Ok, thanks. Still to much C++ logic in my head ;-) I'm getting rid of
it step-by-step.
--
Robert M. Münch
http://www.saphirion.co
60 matches
Mail list logo
