On Wednesday, 7 February 2018 at 19:25:37 UTC, Ralph Doncaster
wrote:
On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven
Schveighoffer wrote:
Seems like the same code you would need to parse the first is
reusable for the second, no?
On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven
Schveighoffer wrote:
Seems like the same code you would need to parse the first is
reusable for the second, no? I don't see why this deprecation
was necessary, and now we have more
On Thursday, 8 February 2018 at 17:06:55 UTC, H. S. Teoh wrote:
On Thu, Feb 08, 2018 at 08:26:03AM -0500, Steven Schveighoffer
via Digitalmars-d wrote: [...]
The extra data in the object file comes from the inclusion of
the hexStringImpl function, and from the template parameter
(the symbol
On Thursday, 8 February 2018 at 18:31:06 UTC, Walter Bright wrote:
On 2/8/2018 5:26 AM, Steven Schveighoffer wrote:
The extra data in the object file comes from the inclusion of
the hexStringImpl function, and from the template parameter
(the symbol
On Thursday, 8 February 2018 at 15:59:28 UTC, Nicholas Wilson
wrote:
On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster
wrote:
On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster
wrote:
On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas
Wilson wrote:
For OpenCL I
On Thursday, 8 February 2018 at 18:49:51 UTC, Steven
Schveighoffer wrote:
I wonder if it's an issue with how obj2asm prints it out?
Surely, that data array must be contiguous, and they must be
bytes. Otherwise the resulting code would be wrong.
OK. I didn't even know about obj2asm until you
On Thursday, 8 February 2018 at 01:27:46 UTC, Seb wrote:
On Thursday, 8 February 2018 at 00:55:28 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven
Schveighoffer wrote:
[...]
They are deprecated:
On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:
On 2/7/2018 8:03 AM, Ralph Doncaster wrote:
As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.
When I tried it:
import std.conv;
void
On Thursday, 8 February 2018 at 01:53:43 UTC, Walter Bright wrote:
On 2/7/2018 11:29 AM, Ralph Doncaster wrote:
I just did a quick check, and with DMD v2.078.1, the hexString
template increases code size by ~300 bytes vs the hex literal.
So yet one more reason to prefer the hex literals.
On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
I am sure there will be lots of opinions regarding this post
but its suffice to say that my decision to go with Go ( no pun
intended ) is finally. I hope this final post is some
indication of the issues that have plagued my decision
On Tuesday, 6 February 2018 at 20:55:31 UTC, Adam D. Ruppe wrote:
On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster
wrote:
The opencl package in dub is a crude wrapper around the
original C API. I couldn't find any sha lib, so I've started
porting a reference sha3 implementation
On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
Which language futures by your opinion make D harder?
Too many choices. I tend to obsess over the best way to do
something, and when the language gives me several options I want
to try them all. One example is constants (that would
On Friday, 9 February 2018 at 15:46:56 UTC, Mike Parker wrote:
On Friday, 9 February 2018 at 15:37:12 UTC, Ralph Doncaster
wrote:
I think you are proving my point. You say there is no
difference between:
const MAX_IN = 20;
vs
immutable MAX_IN = 20;
So now I have to try both, and look at
On Friday, 9 February 2018 at 15:09:10 UTC, Mike Parker wrote:
On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster
wrote:
const auto MAX_IN = 20;
const MAX_IN = 20;
The auto is superfluous and is only needed when there's no
storage class or type.
Others say to use enums. It
On Friday, 9 February 2018 at 15:03:02 UTC, Adam D. Ruppe wrote:
On Friday, 9 February 2018 at 14:59:38 UTC, Ralph Doncaster
wrote:
The docs say using "private" will keep the symbol out of the
file, but that is not true.
https://dlang.org/spec/attribute.html#static
That sentence isn't well
On Friday, 9 February 2018 at 16:33:21 UTC, bachmeier wrote:
On Friday, 9 February 2018 at 16:05:52 UTC, Ralph Doncaster
wrote:
It might be clear and simple to you, but it's not to me. And
I'm a rather advanced developer.
While there are lots of things I like about D compared to C++
such as
On Friday, 9 February 2018 at 21:05:10 UTC, H. S. Teoh wrote:
On Fri, Feb 09, 2018 at 08:49:24PM +, Meta via
Digitalmars-d wrote: [...]
I think the perception of D being complicated is more from
programmers coming from Python/Ruby/JS (and to a lesser
extent, Haskell/Scheme/Java). D is
On Wednesday, 7 February 2018 at 22:31:58 UTC, John Gabriele
wrote:
I'm not sure how long dub has been around, but having an easy
to use CPAN-alike (online module repo) is HUGE. Dub is great
for sales. The better dub and the repo gets, the more
attractive D gets.
I completely agree that the
None of the forum group descriptions seem to apply to discussions
about the dlang.org web site, so I'm posting this in general.
Selecting "Articles" from the "Documentation" tab gives a 404
error.
https://dlang.org/articles.html
It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals
From reading forum posts I managed to figure out that HexStrings
are prefixed with an x. i.e. x"deadbeef"
On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson
wrote:
On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster
wrote:
I, like you, may end up jumping off the ship though. I've
done a bit of work with golang before, so maybe I'll take
another look at it. The opencl
On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster
wrote:
On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson
wrote:
For OpenCL I develop and maintain DCompute:
http://code.dlang.org/packages/dcompute
https://github.com/libmir/dcompute
It has a much beautified interface
On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven
Schveighoffer wrote:
On 2/7/18 9:59 AM, Ralph Doncaster wrote:
It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals
From
On Wednesday, 7 February 2018 at 15:54:05 UTC, Ralph Doncaster
wrote:
Doesn't that go against the idea of -betterC, or will std.conv
work with -betterC.
p.s. contrary to what the deprecation notice says, hex strings
are very often used in crypto/hashing test cases. Most hash
specs have
I get this error when I try the following code:
struct Record {
union { ubyte[8] bytes; ulong l;}
uint key;
}
Record r;
r.l = parse!ulong("deadbeef", 16);
However the following works:
string s = "deadbeef";
r.l = parse!ulong(s, 16);
And another way that works:
r.l =
On Tuesday, 6 February 2018 at 17:47:30 UTC, Adam D. Ruppe wrote:
On Tuesday, 6 February 2018 at 17:33:43 UTC, Ralph Doncaster
wrote:
I get this error when I try the following code:
parse specifically works with a reference input it can advance.
From the docs:
"It takes the input by
I've been reading std.conv and std.range, trying to figure out a
high-level way of converting a hex string to bytes. The only way
I've been able to do it is through pointer access:
import std.stdio;
import std.string;
import std.conv;
void main()
{
immutable char* hex =
On Tuesday, 6 February 2018 at 18:33:02 UTC, Ralph Doncaster
wrote:
I've been reading std.conv and std.range, trying to figure out
a high-level way of converting a hex string to bytes. The only
way I've been able to do it is through pointer access:
import std.stdio;
import std.string;
import
This seems odd to me. Is there a way I can make a function that
takes an array of any type but only of a specific size in bytes?
void.d(8): Error: function void.foo (void[12] arr) is not
callable using argument types (uint[3])
Failed: ["/usr/bin/dmd", "-v", "-o-", "void.d", "-I."]
void
On Friday, 9 February 2018 at 16:28:50 UTC, Nicholas Wilson wrote:
On Friday, 9 February 2018 at 15:50:24 UTC, Ralph Doncaster
wrote:
Is there a way I can make a function that takes an array of any
type but only of a specific size in bytes?
With a template that constrains the types size:
On Friday, 9 February 2018 at 15:24:27 UTC, Mike Parker wrote:
On Friday, 9 February 2018 at 15:05:33 UTC, Ralph Doncaster
wrote:
This seems odd to me. Is there a way I can make a function
that takes an array of any type but only of a specific size in
bytes?
void.d(8): Error: function
On Tuesday, 6 February 2018 at 18:33:02 UTC, Ralph Doncaster
wrote:
I've been reading std.conv and std.range, trying to figure out
a high-level way of converting a hex string to bytes. The only
way I've been able to do it is through pointer access:
import std.stdio;
import std.string;
import
32 matches
Mail list logo
