On Friday, 28 September 2012 at 16:07:51 UTC, deadalnix wrote:
Le 28/09/2012 07:43, Walter Bright a écrit :
talking about Component Programming in D on Oct. 2.
http://gotocon.com/aarhus-2012/schedule/tuesday.jsp
See you there! (use promotion code brig1000 when registering
and you'll
get a
On Tuesday, 2 October 2012 at 09:22:12 UTC, Jonas Drewsen wrote:
On Tuesday, 2 October 2012 at 06:24:13 UTC, Paulo Pinto wrote:
On Friday, 28 September 2012 at 16:07:51 UTC, deadalnix wrote:
Le 28/09/2012 07:43, Walter Bright a écrit :
talking about Component Programming in D on Oct. 2.
The new version adds support for UDP sockets and a lot of smaller
improvements and fixes, for example in the Diet parser and the REST
interface generator (see http://vibed.org/blog/posts/vibe-release-0.7.8
for details). Thanks for all contributions!
I've also done some improvements to the API
Hi,
I am very new to this, but cannot compile/run this under Windows 7
64-bit. I tried to run an http_example with this result:
c:\vibe\bin\..\source\vibe\vpm\dependency.d(117): Error: undefined
identifier HEAD
c:\vibe\bin\..\source\vibe\vpm\dependency.d(117): Error: constructor
Am 10/2/2012 8:26 PM, schrieb Lubos Pintes:
Hi,
I am very new to this, but cannot compile/run this under Windows 7
64-bit. I tried to run an http_example with this result:
Sorry, I think you checked out a bad commit on master. We just made some
changes to the VPM system. Should compile again
On Tuesday, 2 October 2012 at 21:51:45 UTC, Rene Zwanenburg wrote:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
Andrei
John D. Cook mentions Walter's talk in his blog post at
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
Andrei
Nice article!
On 10/2/12, Rene Zwanenburg renezwanenb...@gmail.com wrote:
John D. Cook mentions Walter's talk in his blog post at
http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/comment-page-1/#comment-249100
He also mentions there might be a video coming up of the event. If
that's true,
On 10/2/12 6:14 PM, Paulo Pinto wrote:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
Andrei
Nice article!
I liked it the most of all I've read from Walter.
Andrei
Le 03/10/2012 00:45, Andrei Alexandrescu a écrit :
On 10/2/12 6:14 PM, Paulo Pinto wrote:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
Andrei
Nice article!
I liked it the most of
On Tue, 02 Oct 2012 08:24:27 +0200
Paulo Pinto pj...@progtools.org wrote:
Been there once, visiting some friends at the university, they
used to complain that the city is quite boring to live on, at
least as a student.
Students will say that about any city. It's the standard college excuse
On Tue, 02 Oct 2012 17:27:55 -0400
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
Excellent article!
On Tuesday, October 02, 2012 17:27:55 Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in
_d/
It's definitely the sort of article that we've needed to show what we're trying
to do with ranges.
- Jonathan M Davis
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
Andrei
The article contains a bug due to the pernicious behaviour of
seedless reduce.
This section:
Just to show how flexible algorithms
On Wed, 03 Oct 2012 03:05:08 +0200
Jonathan M Davis jmdavisp...@gmx.com wrote:
On Tuesday, October 02, 2012 17:27:55 Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in
_d/
It's definitely the sort of article that we've needed to show
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
Andrei
The article contains a bug due to the pernicious behaviour of
seedless reduce.
This section:
Just to show how flexible algorithms
On 02-Oct-12 06:28, F i L wrote:
D has a big
advantage over C/C++ here because of UFCS, in that we can write external
functions that appear no different to encapsulated object methods. That
combined with public-aliasing means the end-user only sees our pretty
functions, but we're not
On Monday, 1 October 2012 at 22:47:48 UTC, Timon Gehr wrote:
A D compiler is also a D interpreter. I wouldn't even bother
with D if this wasn't the case.
A D compiler _contains_ a limited interpreter for constant
expression evaluation. This has limitations such as not being
able to
On 01/10/12 07:40, Tommi wrote:
import std.stdio;
int pow2(int val) pure
{
if (__ctfe)
return 6;
else
return val * val;
}
void main()
{
assert(pow2(3) == 9);
static assert(pow2(3) == 6);
writeln(9 = 6 ... I knew it! '6' was faking it all
On Tuesday, October 02, 2012 09:45:10 Don Clugston wrote:
On 01/10/12 21:30, Adam D. Ruppe wrote:
On Monday, 1 October 2012 at 19:22:37 UTC, Philippe Sigaud wrote:
Something I wanted to ask for a long time: is there any runtime speed
penalty in using __ctfe?
No. What happens is when it
On 10/1/2012 7:22 PM, Steven Schveighoffer wrote:
However, we can't require an import to use a bizarre
specifier, and you can't link un@safe code to a specifier, so the zstr
concept is far superior in requiring the user to know what he is doing,
and having the compiler enforce that.
Yup.
Am Mon, 01 Oct 2012 19:18:46 +0200
schrieb Jacob Carlborg d...@me.com:
On 2012-10-01 17:06, Johannes Pfau wrote:
the problem is that we don't want the C main function in a shared
libgdruntime.so, because you might want to use libgdruntime.so in a
C/C++ app which has it's own main
On 7 August 2012 16:56, jerro a...@a.com wrote:
That said, almost all simd opcodes are directly accessible in std.simd.
There are relatively few obscure operations that don't have a representing
function.
The unpck/shuf example above for instance, they both effectively perform a
sort of
Andrej Mitrovic wrote:
On 10/1/12, Piotr Szturmaj bncr...@jadamspam.pl wrote:
For example C binding writers may change:
extern(C) char* getstr();
to
extern(C) cstring getstr();
I don't think you can reliably do that because of semantics w.r.t.
passing parameters on the stack vs in
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.477.1349164468.5162.digitalmar...@puremagic.com...
By the way, why is it not used in static if? That's what most of us would
have
expected (and it frequently seems to trip people up). I assume that it's
due
to some
On 8 August 2012 04:45, F i L witte2...@gmail.com wrote:
Manu wrote:
I'm not sure why the performance would suffer when placing it in a struct.
I suspect it's because the struct causes the vectors to become unaligned,
and that impacts performance a LOT. Walter has recently made some changes
On 8 August 2012 07:54, F i L witte2...@gmail.com wrote:
F i L wrote:
Okay, that makes a lot of sense and is inline with what I was reading
last night about FPU/SSE assembly code. However I'm also a bit confused. At
some point, like in your hightmap example, I'm going to need to do
On 8 August 2012 14:14, F i L witte2...@gmail.com wrote:
David Nadlinger wrote:
objdump, otool – depending on your OS.
Hey, nice tools. Good to know, thanks!
Manu:
Here's the disassembly for my benchmark code earlier, isolated between
StopWatch .start()/.stop()
On 2 October 2012 05:28, F i L witte2...@gmail.com wrote:
Not to resurrect the dead, I just wanted to share an article I came across
concerning SIMD with Manu..
http://www.gamasutra.com/view/**feature/4248/designing_fast_**
On Tuesday, 2 October 2012 at 08:17:33 UTC, Manu wrote:
On 7 August 2012 16:56, jerro a...@a.com wrote:
That said, almost all simd opcodes are directly accessible in
std.simd.
There are relatively few obscure operations that don't have a
representing
function.
The unpck/shuf example above
The problem
---
String literals in D are a little bit magical; they have a trailing \0.
This means that is possible to write,
printf(Hello, World!\n);
without including a trailing \0. This is important for compatibility
with C. This trailing \0 is mentioned in the spec but only
On Tuesday, 2 October 2012 at 11:10:46 UTC, Don Clugston wrote:
The problem
---
String literals in D are a little bit magical; they have a
trailing \0. This means that is possible to write,
printf(Hello, World!\n);
without including a trailing \0. This is important for
Well the whole mess come from the fact that D conflate C string and D
string.
The first problem come from the fact that D array are implicitly
convertible to pointer. So calling D function that expect a char* is
possible with D string even if it is unsafe and will not work in the
general
On 10/2/12, Don Clugston d...@nospam.com wrote:
A proposal to clean up this mess
Any compile-time value of type immutable(char)[] or const(char)[],
behaves a string literals currently do, and will have a \0 appended when
it is stored in the executable.
ie,
On Saturday, 29 September 2012 at 16:34:41 UTC, Andrei
Alexandrescu wrote:
On 9/29/12 11:30 AM, Mr. Anonymous wrote:
I think documentation is really important, and something has
to be done
about it. How can a newcomer get started with D when he
doesn't have a
readable documentation of Phobos?
On 10/2/12 4:09 AM, Walter Bright wrote:
On 10/1/2012 7:22 PM, Steven Schveighoffer wrote:
Does it make sense for Phobos to provide such a shortcut in an obscure
header somewhere? Like std.cstring? Or should we just say roll your own
if you need it?
As a matter of principle, I really don't
Le 01/10/2012 22:33, Vladimir Panteleev a écrit :
On Monday, 1 October 2012 at 12:12:52 UTC, deadalnix wrote:
Le 01/10/2012 13:29, Vladimir Panteleev a écrit :
On Monday, 1 October 2012 at 10:56:36 UTC, deadalnix wrote:
How does to!string know that the string is 0 terminated ?
By convention
On 02/10/12 14:02, Andrej Mitrovic wrote:
On 10/2/12, Don Clugston d...@nospam.com wrote:
A proposal to clean up this mess
Any compile-time value of type immutable(char)[] or const(char)[],
behaves a string literals currently do, and will have a \0 appended
Le 02/10/2012 03:13, Walter Bright a écrit :
On 9/30/2012 11:31 AM, deadalnix wrote:
If you know that a string is 0 terminated, you can easily create a slice
from it as follow :
char* myZeroTerminatedString;
char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)];
It is clean and
On 02/10/12 13:26, deadalnix wrote:
Well the whole mess come from the fact that D conflate C string and D
string.
The first problem come from the fact that D array are implicitly
convertible to pointer. So calling D function that expect a char* is
possible with D string even if it is unsafe and
On 2012-10-02 15:15, Manu wrote:
Is it possible?
Eg:
struct Event(T... = (int, float))
{
void F(T...); // - should default to F(int, float)
}
Does anyone have any clever tricks that will work in this scenario? Some
magic tuple syntax?
struct Event
{
static if (T.length ==
On 02/10/12 13:18, Tobias Pankrath wrote:
On Tuesday, 2 October 2012 at 11:10:46 UTC, Don Clugston wrote:
The problem
---
String literals in D are a little bit magical; they have a trailing
\0. This means that is possible to write,
printf(Hello, World!\n);
without including a
If you've ever worked on a template that needs to index a range,
you may have run into this problem: What is the type you should
use to index an RA range?
The problem may not sound like much, but it is a royal pain in
the ass when trying to write wrapper ranges, such as
std.algorithm.map.
On 2 October 2012 13:49, jerro a...@a.com wrote:
I don't think it is possible to think of all usages of this, but for every
simd instruction there are valid usages. At least for writing pfft, I found
shuffling two vectors very useful. For, example, I needed a function that
takes a small,
module program;
import std.stdio;
import std.traits;
import std.typetuple;
struct Event (T...) {
alias EraseAll!(void, TypeTuple!(T,
Select!(T.length 1, int, void),
Select!(T.length 2, float, void),
)) T2;
void F (T2 args) {
writeln(typeid(typeof(args)));
}
}
void
On 2 October 2012 16:24, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 10/2/12, Manu turkey...@gmail.com wrote:
Does anyone have any clever tricks that will work in this scenario? Some
magic tuple syntax?
Without resorting to helper templates I only know of using this internal
On 09/27/2012 12:02 PM, Joseph Rushton Wakeling wrote:
I'd love to, but it would be irresponsible to commit to it as (right now
especially) I don't have a very good idea of what time I'll be able to offer.
Just to follow up here -- a couple of days ago I pulled LDC from GitHub and
built it.
Or maybe... This seems like a much better solution:
module program;
import std.stdio;
import std.traits;
import std.typetuple;
template SelectTrue (bool condition, T) {
static if (condition)
alias T SelectTrue;
}
struct Event (T...) {
alias TypeTuple!(T,
SelectTrue!(T.length 1,
2012/10/2 Don Clugston d...@nospam.com:
The problem
---
String literals in D are a little bit magical; they have a trailing \0. This
means that is possible to write,
printf(Hello, World!\n);
without including a trailing \0. This is important for compatibility with C.
This
And the simplest solution wins:
module program;
import std.stdio;
import std.traits;
import std.typetuple;
struct Event (T1 = int, T2 = float, Telse...) {
alias TypeTuple!(T1, T2, Telse) T;
void F (T args) {
writeln(typeid(typeof(args)));
}
}
void main () {
Event!() e1;
On Tuesday, 2 October 2012 at 11:10:46 UTC, Don Clugston wrote:
[SNIP]
A proposal to clean up this mess
[SNIP]
While I think it is convenient to be able to write
'printf(world);', as you point out, I think that the fact that
it works inconsistently (and by that, I mean there are rules
and
On 2 October 2012 16:45, Manu turkey...@gmail.com wrote:
On 2 October 2012 16:24, Andrej Mitrovic andrej.mitrov...@gmail.comwrote:
On 10/2/12, Manu turkey...@gmail.com wrote:
Does anyone have any clever tricks that will work in this scenario? Some
magic tuple syntax?
Without resorting to
Interesting, I vaguely remember that Eiffel has a 'once' keyword,
but I'm not sure if it could help here.
Recent discussions on the zero terminated string problems and
inconsistency of string literals has me, again, wondering why D doesn't
have a 'type' to represent C's zero terminated strings. It seems to me
that having a type, and typing C functions with it would solve a lot of
problems.
Le 02/10/2012 15:12, Don Clugston a écrit :
On 02/10/12 13:26, deadalnix wrote:
Well the whole mess come from the fact that D conflate C string and D
string.
The first problem come from the fact that D array are implicitly
convertible to pointer. So calling D function that expect a char* is
On 10/2/12 7:11 AM, Don Clugston wrote:
The problem
---
String literals in D are a little bit magical; they have a trailing \0.
[snip]
I don't mean to be Debbie Downer on this because I reckon it addresses
an issue that some have, although I never do. With that warning, a few
candid
Am 02.10.2012 16:55, schrieb Regan Heath:
Recent discussions on the zero terminated string problems and
inconsistency of string literals has me, again, wondering why D doesn't
have a 'type' to represent C's zero terminated strings. It seems to me
that having a type, and typing C functions with
On Tuesday, 2 October 2012 at 15:14:10 UTC, Andrei Alexandrescu
wrote:
However, so far I held off of defining such a range because
C-strings are seldom useful in D code [...]
I think your view of what is common in D code is not
representative. You are primarily a library writer, which means
On 10/2/12, Manu turkey...@gmail.com wrote:
Actually, this leaves a problem...
Distinction between:
Event x; // using defaults
and
Event!() x; // explicitly selecting none (which would fall back to the
defaults)
Is such a distinction possible? I presume not...
Well actually you can't
On 2 October 2012 18:56, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 10/2/12, Manu turkey...@gmail.com wrote:
Actually, this leaves a problem...
Distinction between:
Event x; // using defaults
and
Event!() x; // explicitly selecting none (which would fall back to the
Manu wrote:
These are indeed common gotchas. But they don't necessarily
apply to D, and
if they do, then they should be bugged and hopefully addressed.
There is no
reason that D needs to follow these typical performance
patterns from C.
It's worth noting that not all C compilers suffer from
On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra wrote:
If you've ever worked on a template that needs to index a
range, you may have run into this problem: What is the type you
should use to index an RA range?
Forgive my ignorance. What's wrong with size_t?
On Monday, 1 October 2012 at 12:28:33 UTC, bearophile wrote:
Our results from 14 Java applications indicates that 72-82% of
fields are stationary
programmers are sometimes forced (or voluntarily choose) to
initialise fields late (i.e. after the constructor has
completed). This prevents such
On 10/2/12, Manu turkey...@gmail.com wrote:
Are you sure it's not fixed? I'm sure I do it all the time... :/
Or I'm smoking some really good stuff.
I'd really like to see how you do it. If not, I'll have some of that
stuff you're having, thanks. :p
On Tuesday, 2 October 2012 at 13:46:58 UTC, Joseph Rushton
Wakeling wrote:
The executables produced are nice and fast -- maybe about
10-15% slower than GDC for the number-crunching code I tested,
[…]
Is any of the code public, in the sense that you could give e.g.
me access for benchmarking
On 10/02/2012 06:14 PM, David Nadlinger wrote:
Is any of the code public, in the sense that you could give e.g. me access for
benchmarking purposes? We are currently using a presumably suboptimal
optimization pass schedule, which for example doesn't include the auto
vectorizer, but are going to
On 2012-10-02, 18:09, Peter Alexander wrote:
On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra wrote:
If you've ever worked on a template that needs to index a range, you
may have run into this problem: What is the type you should use to
index an RA range?
Forgive my ignorance.
On Tuesday, 2 October 2012 at 16:09:16 UTC, Peter Alexander wrote:
On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra wrote:
If you've ever worked on a template that needs to index a
range, you may have run into this problem: What is the type
you should use to index an RA range?
On Tuesday, 2 October 2012 at 16:29:28 UTC, Simen Kjaeraas wrote:
On 2012-10-02, 18:09, Peter Alexander wrote:
On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra
wrote:
If you've ever worked on a template that needs to index a
range, you may have run into this problem: What is the type
On Tuesday, 2 October 2012 at 16:44:48 UTC, monarch_dodra wrote:
On Tuesday, 2 October 2012 at 16:09:16 UTC, Peter Alexander
wrote:
On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra
wrote:
If you've ever worked on a template that needs to index a
range, you may have run into this
On Tuesday, 2 October 2012 at 16:44:48 UTC, monarch_dodra wrote:
On Tuesday, 2 October 2012 at 16:09:16 UTC, Peter Alexander
wrote:
On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra
wrote:
If you've ever worked on a template that needs to index a
range, you may have run into this
monarch_dodra wrote:
On Tuesday, 2 October 2012 at 16:09:16 UTC, Peter Alexander wrote:
On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra wrote:
If you've ever worked on a template that needs to index a range, you
may have run into this problem: What is the type you should use to
index
On Tuesday, October 02, 2012 18:45:50 Peter Alexander wrote:
On Tuesday, 2 October 2012 at 16:29:28 UTC, Simen Kjaeraas wrote:
On 2012-10-02, 18:09, Peter Alexander wrote:
On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra
wrote:
If you've ever worked on a template that needs to
On Tuesday, 2 October 2012 at 16:48:34 UTC, Peter Alexander wrote:
Then don't create ranges that use ushort for indexing and
length. There's no need to.
To be clear, I'm suggesting that all random access ranges
should use size_t, and they will not be random access ranges if
they use anything
Jonathan M Davis wrote:
if length can be specifically ulong and the type is random access, then its
indices will need to be ulong), so unfortunately, the situation is not so
simple that you can always assume size_t (even you should arguably be able
to).
It seems that isRandomAccessRange
On Tuesday, October 02, 2012 15:17:58 monarch_dodra wrote:
You might think just use typeof(length) BUT:
*you aren't even guaranteed that typeof(length) will be
correct! Certain ranges, such as iota, will return a length
usually of type uint, but be indexed with ulong... :/
*Infinite ranges
On Tuesday, 2 October 2012 at 16:59:38 UTC, Jonathan M Davis
wrote:
On Tuesday, October 02, 2012 18:45:50 Peter Alexander wrote:
On Tuesday, 2 October 2012 at 16:29:28 UTC, Simen Kjaeraas
wrote:
On 2012-10-02, 18:09, Peter Alexander wrote:
On Tuesday, 2 October 2012 at 13:17:45 UTC,
On Tuesday, October 02, 2012 19:10:53 monarch_dodra wrote:
Given your stance of I see _zero_ reason to support lengths or
indices smaller than size_t and Types that do that are badly
designed IMHO:
Are you agreeing with my proposed type tightening? If anything,
it weeds out the bad designs
On 10/2/12 12:45 PM, Peter Alexander wrote:
On Tuesday, 2 October 2012 at 16:29:28 UTC, Simen Kjaeraas wrote:
On 2012-10-02, 18:09, Peter Alexander wrote:
On Tuesday, 2 October 2012 at 13:17:45 UTC, monarch_dodra wrote:
If you've ever worked on a template that needs to index a range, you
may
On Tuesday, 2 October 2012 at 17:13:48 UTC, Jonathan M Davis
wrote:
On Tuesday, October 02, 2012 15:17:58 monarch_dodra wrote:
You might think just use typeof(length) BUT:
*you aren't even guaranteed that typeof(length) will be
correct! Certain ranges, such as iota, will return a length
usually
On 10/2/12 1:07 PM, monarch_dodra wrote:
I don't know, forcing an implementer on size_t is pretty gratuitous.
Why can't he be free to choose his own index type?
Too much freedom can be detrimental (as is in this case).
Andrei
On Tuesday, October 02, 2012 19:08:59 Piotr Szturmaj wrote:
Jonathan M Davis wrote:
if length can be specifically ulong and the type is random access, then
its
indices will need to be ulong), so unfortunately, the situation is not so
simple that you can always assume size_t (even you
On Tuesday, 2 October 2012 at 17:07:19 UTC, monarch_dodra wrote:
[SNIP]
You know what, I think I have a better. Idea. All of this came up
because I've had iota break my compiles WAY more often then I'd
have liked. But I think I know of another solution.
I think it would be nice if we
On Tuesday, October 02, 2012 19:37:18 monarch_dodra wrote:
On Tuesday, 2 October 2012 at 17:07:19 UTC, monarch_dodra wrote:
[SNIP]
You know what, I think I have a better. Idea. All of this came up
because I've had iota break my compiles WAY more often then I'd
have liked. But I think I
On 2012-10-02 18:10, Manu wrote:
Are you sure it's not fixed? I'm sure I do it all the time... :/
Or I'm smoking some really good stuff.
It's not needed for functions templates. But it is needed for type
templates.
--
/Jacob Carlborg
On Tuesday, 2 October 2012 at 17:24:32 UTC, Andrei Alexandrescu
wrote:
Yes. Unfortunately there are few, few cases in which size_t is
insufficient (e.g. an input range from a file or a large iota,
both on 32-bit builds). I personally think these are too few to
need formal support.
I'd throw
On Tue, 02 Oct 2012 04:09:43 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 10/1/2012 7:22 PM, Steven Schveighoffer wrote:
Does it make sense for Phobos to provide such a shortcut in an obscure
header somewhere? Like std.cstring? Or should we just say roll your own
if you need it?
On Tuesday, 2 October 2012 at 02:22:33 UTC, Steven Schveighoffer
wrote:
@system char[] zstr(char *s) { return s[0..strlen(s)]; }
[…]
Does it make sense for Phobos to provide such a shortcut in an
obscure header somewhere? Like std.cstring? Or should we just
say roll your own if you need
Hi,
I am tempted to start D programming but for me it is crucrial to
be able to parallelize for-loops as can be done with openMP for
C/C++ (mainly @pragma omp parallel for, @pragma omp critical).
I have already seen the std.parallelism library but I'm unsure
whether it can provide me with the
On Tuesday, 2 October 2012 at 18:45:24 UTC, David Nadlinger wrote:
On Tuesday, 2 October 2012 at 17:24:32 UTC, Andrei Alexandrescu
wrote:
Yes. Unfortunately there are few, few cases in which size_t is
insufficient (e.g. an input range from a file or a large iota,
both on 32-bit builds). I
http://forum.dlang.org/thread/k4f4tp$8p4$1...@digitalmars.com#post-k4fdsc:24v9u:241:40digitalmars.com
vibe.d got clickable types in documentation, perhaps this could
be somehow integrated into phobos docs?
On 10/02/2012 03:15 PM, Manu wrote:
struct Event(T... = (int, float))
{
void F(T...); // - should default to F(int, float)
}
template Event(){alias Event!(int,float) Event;}
struct Event(T...){
void F(T...);
}
On Tue, 02 Oct 2012 15:17:42 -0400, David Nadlinger s...@klickverbot.at
wrote:
On Tuesday, 2 October 2012 at 02:22:33 UTC, Steven Schveighoffer wrote:
@system char[] zstr(char *s) { return s[0..strlen(s)]; }
[…]
Does it make sense for Phobos to provide such a shortcut in an obscure
On Tuesday, 2 October 2012 at 19:31:33 UTC, Steven Schveighoffer
wrote:
On Tue, 02 Oct 2012 15:17:42 -0400, David Nadlinger
s...@klickverbot.at wrote:
On Tuesday, 2 October 2012 at 02:22:33 UTC, Steven
Schveighoffer wrote:
@system char[] zstr(char *s) { return s[0..strlen(s)]; }
[…]
Does
On Tuesday, 2 October 2012 at 19:34:31 UTC, David Nadlinger wrote:
Well, make it to!char(char*) then! ;)
Oh dear, this doesn't get better: Of course, I've meant to write
»to!(char[])(char*)«.
David
On Tuesday, 2 October 2012 at 19:15:19 UTC, Farmer wrote:
Hi,
I am tempted to start D programming but for me it is crucrial
to be able to parallelize for-loops as can be done with openMP
for C/C++ (mainly @pragma omp parallel for, @pragma omp
critical).
I have already seen the std.parallelism
On Tuesday, October 02, 2012 20:45:36 David Nadlinger wrote:
On Tuesday, 2 October 2012 at 17:24:32 UTC, Andrei Alexandrescu
wrote:
Yes. Unfortunately there are few, few cases in which size_t is
insufficient (e.g. an input range from a file or a large iota,
both on 32-bit builds). I
On Tue, 02 Oct 2012 15:35:47 -0400, David Nadlinger s...@klickverbot.at
wrote:
On Tuesday, 2 October 2012 at 19:34:31 UTC, David Nadlinger wrote:
Well, make it to!char(char*) then! ;)
Oh dear, this doesn't get better: Of course, I've meant to write
»to!(char[])(char*)«.
Right. I
On Tuesday, 2 October 2012 at 13:36:37 UTC, Manu wrote:
On 2 October 2012 13:49, jerro a...@a.com wrote:
I don't think it is possible to think of all usages of this,
but for every
simd instruction there are valid usages. At least for writing
pfft, I found
shuffling two vectors very useful.
On 2 October 2012 23:52, jerro a...@a.com wrote:
On Tuesday, 2 October 2012 at 13:36:37 UTC, Manu wrote:
On 2 October 2012 13:49, jerro a...@a.com wrote:
I don't think it is possible to think of all usages of this, but for
every
simd instruction there are valid usages. At least for
1 - 100 of 160 matches
Mail list logo
