On 9 June 2013 10:36, Roderick Gibson wrote:
> I get a compiler assert failing when trying to compile the follow minimal
> case:
>
> import core.simd;
>
> void main() {
> auto arr = si;
> }
>
> const float4 si = [1f, 1f, 1f, 1f];
>
> This compiles fine:
>
> import core.simd;
>
> void main
On 8 June 2013 21:27, Flamaros wrote:
> On Saturday, 8 June 2013 at 03:59:25 UTC, Manu wrote:
>
>> On 8 June 2013 13:25, Walter Bright wrote:
>>
>> On 6/7/2013 5:15 PM, Manu wrote:
>>>
>>> I can tell you that in my case, we export a lot(/most) things. Renderer
api,
sound api, etc are
On 6/5/2013 3:18 AM, Hisayuki Mima wrote:
I held a very small D conference, The Day of D, in Fukushima on March 15
and 16, 2013.
This is a simple report of it. (Sorry, All of videos and slides are in
Japanese.)
There were three speakers in the conference: I (ordinary D user,
developing ctpg), Ke
On 9 June 2013 02:39, Walter Bright wrote:
> On 6/7/2013 8:59 PM, Manu wrote:
>
>> Because they embody functionality, not just data. That's just how many
>> many
>> programmers write code.
>> Go to university for a couple of years, see what they tell you... ;)
>> Some of these systems can effecti
On 6/8/2013 4:35 PM, Timon Gehr wrote:
2. My last pull request has rotten for 6 months now.
Sorry about that.
On 6/8/2013 5:36 PM, Roderick Gibson wrote:
I get a compiler assert failing when trying to compile the follow minimal case:
Please report all bugs to:
http://d.puremagic.com/issues/
I get a compiler assert failing when trying to compile the follow
minimal case:
import core.simd;
void main() {
auto arr = si;
}
const float4 si = [1f, 1f, 1f, 1f];
This compiles fine:
import core.simd;
void main() {
auto arr = si;
}
float4 si = [1f, 1f, 1f, 1f];
Should I
On Sunday, 9 June 2013 at 00:03:04 UTC, Peter Williams wrote:
On 09/06/13 08:54, David Nadlinger wrote:
On Saturday, 8 June 2013 at 22:25:14 UTC, Peter Williams wrote:
Shouldn't have to import std.algorithm just to sort an array.
Why not?
Because it's large with a lot of stuff unrelated to
On Sunday, 9 June 2013 at 00:03:04 UTC, Peter Williams wrote:
On 09/06/13 08:54, David Nadlinger wrote:
On Saturday, 8 June 2013 at 22:25:14 UTC, Peter Williams wrote:
Shouldn't have to import std.algorithm just to sort an array.
Why not?
Because it's large with a lot of stuff unrelated to
On 09/06/13 08:54, David Nadlinger wrote:
On Saturday, 8 June 2013 at 22:25:14 UTC, Peter Williams wrote:
Shouldn't have to import std.algorithm just to sort an array.
Why not?
Because it's large with a lot of stuff unrelated to sorting.
Peter
PS A few weeks ago I would have said "large and
On 06/08/2013 12:43 AM, Walter Bright wrote:
On 6/7/2013 2:52 AM, Timon Gehr wrote:
You are certainly wrong about the value range propagation part. The
transformers
for the bitwise operators are not the best possible.
ubyte x = ((y&252)^2)+1;
The above term can be easily proven to fit into uby
Peter Williams:
Rather than deprecate it why not fix it? Shouldn't have to
import std.algorithm just to sort an array.
Generally you want to keep the compiler (all its layers) as
simpler as possible, to make it simpler to compile, debug and
develop. A sort is implementable very well in libr
On Saturday, 8 June 2013 at 22:25:14 UTC, Peter Williams wrote:
Shouldn't have to import std.algorithm just to sort an array.
Why not?
David
On 08/06/13 18:51, Jonathan M Davis wrote:
On Saturday, June 08, 2013 10:30:52 Stephan Schiffels wrote:
Hi,
I know it has been discussed previously to deprecate the builtin
sort. I don't know the status of this, but I observed the
following problem.
With dmd, druntime and phobos all on 2.063,
On 05/31/2013 11:17 PM, David Piepgrass wrote:
I'm adding D-style ranges to my new C# collections library. In case
anyone would like to comment, please see here:
http://loyc-etc.blogspot.ca/2013/06/d-style-ranges-in-c-net.html
(I wrote the following comment on the blog page but it is not visib
On 6/8/2013 11:05 AM, Eric wrote:
The following code will cause the compiler to crash:
All bug reports should be posted here:
http://d.puremagic.com/issues/
On Saturday, 8 June 2013 at 18:05:16 UTC, Eric wrote:
The following code will cause the compiler to crash:
import std.traits;
interface Identity(V, K) if (hasMember!(V, "k")) {
}
class Foo(K): Identity!(Foo!K, K) {
K k;
}
void main() {
new Foo!double;
}
This occurs on both compiler v
The following code will cause the compiler to crash:
import std.traits;
interface Identity(V, K) if (hasMember!(V, "k")) {
}
class Foo(K): Identity!(Foo!K, K) {
K k;
}
void main() {
new Foo!double;
}
This occurs on both compiler versions, 2.062 and
v2.063-devel-53aa503.
At a minimu
On 6/8/13 1:53 PM, Adam D. Ruppe wrote:
On Saturday, 8 June 2013 at 05:11:11 UTC, Walter Bright wrote:
Also, obj2asm gives nicer disassembly :-)
You know what would rok? If it could output code that you could
copy/paste directly into D's iasm without having to go back and add
semicolons, chang
On Saturday, 8 June 2013 at 05:11:11 UTC, Walter Bright wrote:
Also, obj2asm gives nicer disassembly :-)
You know what would rok? If it could output code that you could
copy/paste directly into D's iasm without having to go back and
add semicolons, change 0eh to 0x0e, etc.
On 6/7/2013 9:15 PM, Juan Manuel Cabo wrote:
So I think it is a low hanging fruit because IMO the
speed difference is either because the GCC loop jump is
64bit aligned,
http://d.puremagic.com/issues/show_bug.cgi?id=10301
Am 08.06.2013 19:26, schrieb Walter Bright:
On 6/8/2013 12:37 AM, dennis luehring wrote:
Am 08.06.2013 09:28, schrieb Walter Bright:
On 6/7/2013 11:11 PM, Juan Manuel Cabo wrote:
I now used inline assembler, and can confidently say
that the difference is because of the alignment.
Thanks, thi
On Saturday, 8 June 2013 at 17:27:48 UTC, monarch_dodra wrote:
On Saturday, 8 June 2013 at 16:21:26 UTC, deadalnix wrote:
{} is a lambda already. The first set of () is optional.
Oh Yeah. Didn't know that. You learn something new every day.
...but for that to work, (it seems) you have actual
On Saturday, 8 June 2013 at 16:21:26 UTC, deadalnix wrote:
{} is a lambda already. The first set of () is optional.
Oh Yeah. Didn't know that. You learn something new every day.
...but for that to work, (it seems) you have actually store or
pass the lambda, or all the parser sees is a plain
On 6/8/2013 12:37 AM, dennis luehring wrote:
Am 08.06.2013 09:28, schrieb Walter Bright:
On 6/7/2013 11:11 PM, Juan Manuel Cabo wrote:
I now used inline assembler, and can confidently say
that the difference is because of the alignment.
Thanks, this is great information.
sadly not for x64
On Saturday, 8 June 2013 at 07:10:29 UTC, Simen Kjaeraas wrote:
On Sat, 08 Jun 2013 04:09:25 +0200, Tyler Jameson Little
wrote:
What is the -safe option? I don't see it in DMD help.
@safe is specified without @nogc, but calling function is
@nogc, so I think that #1 should be chosen.
I pul
On Saturday, 8 June 2013 at 16:21:26 UTC, deadalnix wrote:
On Saturday, 8 June 2013 at 16:13:28 UTC, monarch_dodra wrote:
On Saturday, 8 June 2013 at 15:56:47 UTC, deadalnix wrote:
Sound like a nice idiom. Why is the first set of () needed ?
Can we change the grammar to remove them ?
It's b
On 06/08/2013 06:39 PM, Walter Bright wrote:
> So they don't need to be classes at all. It's not about embodying
> functionality
> vs data. It's about having a value type vs a polymorphic ref type.
I've had quite good experiences using template mixins to generate struct
polymorphism (in practice
On 6/7/2013 8:59 PM, Manu wrote:
Because they embody functionality, not just data. That's just how many many
programmers write code.
Go to university for a couple of years, see what they tell you... ;)
Some of these systems can effectively be considered plugins. Consider
OpenGL/DirectX? DirectSou
On Saturday, 8 June 2013 at 16:13:28 UTC, monarch_dodra wrote:
On Saturday, 8 June 2013 at 15:56:47 UTC, deadalnix wrote:
Sound like a nice idiom. Why is the first set of () needed ?
Can we change the grammar to remove them ?
It's because you are actually declaring a lambda that takes no
ar
On Saturday, 8 June 2013 at 15:56:47 UTC, deadalnix wrote:
Sound like a nice idiom. Why is the first set of () needed ?
Can we change the grammar to remove them ?
It's because you are actually declaring a lambda that takes no
arguments, and has no name, and contains a body. BTW, you quoted
On Saturday, 8 June 2013 at 14:52:23 UTC, monarch_dodra wrote:
I remember think that being able to mark specific parts of code
with certain attributes, inside a block, could be very useful.
for example:
void foo()
{
//Code
/Critical section
nothrow {
//code here can't
On 6/8/13 10:45 AM, monarch_dodra wrote:
On Saturday, 8 June 2013 at 14:14:33 UTC, Lars T. Kyllingstad wrote:
On Saturday, 8 June 2013 at 14:08:59 UTC, Lars T. Kyllingstad wrote:
On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu wrote:
However, there are times where it is convenient
EDIT: Sorry: stupid computer sent before I was finished. I was
saying...
I have since learned that you can do this with lambda's
instead, declaring and calling them in a single line:
void foo()
{
//Code
//Critical section
() nothrow //declaration
{ //body
//code her
On 6/8/13 10:19 AM, H. S. Teoh wrote:
If the review manager is also the author, wouldn't he have particular
interest in getting the proposal accepted?
Those should never be the same.
Andrei
I remember think that being able to mark specific parts of code
with certain attributes, inside a block, could be very useful.
for example:
void foo()
{
//Code
/Critical section
nothrow {
//code here can't throw
}
//More code
}
I have since learned tha
On Saturday, 8 June 2013 at 14:14:33 UTC, Lars T. Kyllingstad
wrote:
On Saturday, 8 June 2013 at 14:08:59 UTC, Lars T. Kyllingstad
wrote:
On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu
wrote:
However, there are times where it is convenient to be able
to explode a
path into a struct
On Saturday, 8 June 2013 at 13:26:06 UTC, Andrei Alexandrescu
wrote:
Why? The review manager does not have a particular interest in
getting the proposal accepted or refused; the role is there
just to ensure a fair process.
Andrei
The topic is whether someone could be review manager for their
On Sat, Jun 08, 2013 at 09:26:09AM -0400, Andrei Alexandrescu wrote:
> On 6/8/13 3:30 AM, Jakob Ovrum wrote:
> >On Friday, 7 June 2013 at 22:52:47 UTC, Brad Anderson wrote:
> >>Found the description of the process:
> >>http://wiki.dlang.org/Review/Process
> >>
> >>It's somewhat vague and could prob
On Saturday, 8 June 2013 at 14:08:59 UTC, Lars T. Kyllingstad
wrote:
On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu
wrote:
However, there are times where it is convenient to be able to
explode a
path into a structure, where each part is clearly separate
from the
next.
Tuple!(
On Friday, 7 June 2013 at 17:27:16 UTC, Andrei Alexandrescu wrote:
On 6/7/13 1:04 PM, monarch_dodra wrote:
I think using string as the main form of representation for a
path is fine.
However, there are times where it is convenient to be able to
explode a
path into a structure, where each part
On Saturday, 8 June 2013 at 10:21:58 UTC, Jonas Drewsen wrote:
I am pretty sure I was not the one deciding to start a vote for
std.net.curl back then.
Can't remember who was the review manager though.
That would have been me for the first time round, and then the
other David (i.e. Simcha) fo
On 6/8/13 3:30 AM, Jakob Ovrum wrote:
On Friday, 7 June 2013 at 22:52:47 UTC, Brad Anderson wrote:
Found the description of the process:
http://wiki.dlang.org/Review/Process
It's somewhat vague and could probably use some standard announcement
templates people could use.
Looks like it's actual
On Saturday, 8 June 2013 at 09:16:23 UTC, monarch_dodra wrote:
On Saturday, 8 June 2013 at 08:52:22 UTC, Jonathan M Davis
wrote:
However, we really, really need to deprecate the built-in sort
- especially
when a pair of parens can make the difference between whether
you call the
built-in sort o
On Saturday, 8 June 2013 at 03:59:25 UTC, Manu wrote:
On 8 June 2013 13:25, Walter Bright
wrote:
On 6/7/2013 5:15 PM, Manu wrote:
I can tell you that in my case, we export a lot(/most)
things. Renderer
api,
sound api, etc are often all in their own libraries. So none
of them are
ever
eli
On Saturday, 8 June 2013 at 08:52:22 UTC, Jonathan M Davis wrote:
Hmm, it works just fine on my system (64-bit Linux), so I don't
know why you're
seeing the problem that you're seeing.
Hmm, that's bizarre, but I guess there's no need to understand
this further since things work fine with std
On Saturday, 8 June 2013 at 10:55:37 UTC, Dicebot wrote:
On Saturday, 8 June 2013 at 10:34:17 UTC, deadalnix wrote:
On Saturday, 8 June 2013 at 10:22:42 UTC, Dicebot wrote:
On Saturday, 8 June 2013 at 06:33:48 UTC, deadalnix wrote:
...
Btw, are there any reasons why "export" can't be applied
On Saturday, 8 June 2013 at 10:34:17 UTC, deadalnix wrote:
On Saturday, 8 June 2013 at 10:22:42 UTC, Dicebot wrote:
On Saturday, 8 June 2013 at 06:33:48 UTC, deadalnix wrote:
...
Btw, are there any reasons why "export" can't be applied on
per-method basis instead of whole classes?
For fina
On Saturday, 8 June 2013 at 10:22:42 UTC, Dicebot wrote:
On Saturday, 8 June 2013 at 06:33:48 UTC, deadalnix wrote:
...
Btw, are there any reasons why "export" can't be applied on
per-method basis instead of whole classes?
For final method, no problem, but for virtual method, it is
either
On Saturday, 8 June 2013 at 07:30:03 UTC, Jakob Ovrum wrote:
On Friday, 7 June 2013 at 22:52:47 UTC, Brad Anderson wrote:
Found the description of the process:
http://wiki.dlang.org/Review/Process
It's somewhat vague and could probably use some standard
announcement templates people could use
On Saturday, 8 June 2013 at 06:33:48 UTC, deadalnix wrote:
...
Btw, are there any reasons why "export" can't be applied on
per-method basis instead of whole classes?
On Saturday, 8 June 2013 at 08:52:22 UTC, Jonathan M Davis wrote:
However, we really, really need to deprecate the built-in sort
- especially
when a pair of parens can make the difference between whether
you call the
built-in sort or std.algorithm's sort - and it's particularly
broken with
reg
On Saturday, June 08, 2013 10:30:52 Stephan Schiffels wrote:
> Hi,
>
> I know it has been discussed previously to deprecate the builtin
> sort. I don't know the status of this, but I observed the
> following problem.
>
> With dmd, druntime and phobos all on 2.063, this program runs
> successfully
Hi,
I know it has been discussed previously to deprecate the builtin
sort. I don't know the status of this, but I observed the
following problem.
With dmd, druntime and phobos all on 2.063, this program runs
successfully on a mac:
#!/usr/bin/env rdmd
import std.stdio;
void main() {
in
Am 08.06.2013 09:28, schrieb Walter Bright:
On 6/7/2013 11:11 PM, Juan Manuel Cabo wrote:
I now used inline assembler, and can confidently say
that the difference is because of the alignment.
Thanks, this is great information.
sadly not for x64 :(
On Friday, 7 June 2013 at 22:52:47 UTC, Brad Anderson wrote:
Found the description of the process:
http://wiki.dlang.org/Review/Process
It's somewhat vague and could probably use some standard
announcement templates people could use.
Looks like it's actually two weeks of review, one week of
On 6/7/2013 11:11 PM, Juan Manuel Cabo wrote:
I now used inline assembler, and can confidently say
that the difference is because of the alignment.
Thanks, this is great information.
On Friday, 7 June 2013 at 20:52:53 UTC, Mrzlga wrote:
- Use the library for it and instead make signed(x),
unsigned(x) templates.
This !
On Sat, 08 Jun 2013 04:09:25 +0200, Tyler Jameson Little
wrote:
What is the -safe option? I don't see it in DMD help.
@safe is specified without @nogc, but calling function is @nogc, so I
think that #1 should be chosen.
I pulled that from here: http://dlang.org/memory-safe-d.html
Maybe
59 matches
Mail list logo
