On Monday, 27 June 2016 at 03:09:46 UTC, Meta wrote:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any
type whatsoever
'template';
Still adding D features, I see!
Imitation is the sin
On Monday, 27 June 2016 at 05:33:24 UTC, luminousone wrote:
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any
type whatsoever
'template';
Still adding D features, I see!
Now if only t
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any type
whatsoever
'template';
Still adding D features, I see!
Now if only they could bring over some of D's superior template
syntax, a
On Monday, 27 June 2016 at 04:25:56 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 27 June 2016 at 04:23:10 UTC, Ola Fosheim Grøstad
wrote:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=adds_epi
Or in the context of 8 bit colour vectors:
https://software.intel.com/sites/landi
On Monday, 27 June 2016 at 04:23:10 UTC, Ola Fosheim Grøstad
wrote:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=adds_epi
Or in the context of 8 bit colour vectors:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=adds_epu8
On Sunday, 26 June 2016 at 22:34:29 UTC, Andrei Alexandrescu
wrote:
On 06/26/2016 02:07 PM, ketmar wrote:
On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu
wrote:
See the recent thread "DbI checked integral". Saturation is a
direct
goal, and you should be able to optimize operations
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any type
whatsoever
'template';
Still adding D features, I see!
Imitation is the sincerest form of flattery, so when is
destructuring com
On 26.06.2016 20:08, Iain Buclaw via Digitalmars-d wrote:
On 26 June 2016 at 14:33, Timon Gehr via Digitalmars-d
wrote:
On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote:
Old codegen:
_base = *(getBase());
_lwr = getLowerBound(_base.length);
_upr = getUpperBound(_base.length);
r = {.l
On Sunday, 26 June 2016 at 23:27:41 UTC, Jadbox wrote:
On Saturday, 25 June 2016 at 16:05:08 UTC, ZombineDev wrote:
Overall DMD completes mandel.b for 75.5% of the time of the
previous version, LDC for 62.6% and GDC for 88.1%. The code is
64.9% of the original (in terms of LOC).
This is what
On Sunday, 26 June 2016 at 23:06:02 UTC, Jadbox wrote:
Is there an AWS library in the works for D? It's seriously the
main blocker for me to push adoption of the language internally.
If not, I can try to invest time into making one, but I could
use help.
(fyi, there's one in the works for Ru
On Friday, June 24, 2016 13:54:21 Andrei Alexandrescu via Digitalmars-d wrote:
> On 6/24/16 1:15 PM, Steven Schveighoffer wrote:
> > The problem that hasn't been made clear is, why can't you just write:
> >
> > static if(condition)
> > {
> >
> > ... // some code
> > return;
> >
> > }
> >
>
On Monday, 27 June 2016 at 00:13:46 UTC, mogu wrote:
On Friday, 8 May 2015 at 13:57:56 UTC, Andrea Fontana wrote:
Is "multiple alias this" implementation planned in near
future? It could be useful for a project of mine :)
I need it too, and also do static inheritance.
http://wiki.dlang.org/DIP
On Friday, 8 May 2015 at 13:57:56 UTC, Andrea Fontana wrote:
On Saturday, 27 December 2014 at 12:28:34 UTC, Joseph Rushton
Wakeling wrote:
On 26/12/14 19:53, Daniel N via Digitalmars-d wrote:
Anyway considering the new ways of working, when using the
-dip switch for the
initial few releases, th
On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any type
whatsoever
'template';
Still adding D features, I see!
Now cpp has structured bindings although it's a limited version
of match.
On Sunday, 26 June 2016 at 07:01:57 UTC, ted wrote:
Unsure of exactly how to communicate this one, so posting here.
[snip]
for any dmd >2.068 causes the following error:
dmd: glue.c:809: void
FuncDeclaration_toObjFile(FuncDeclaration*, bool): Assertion
`fd->semanticRun == PASSsemantic3done'
On Sunday, 26 June 2016 at 22:34:29 UTC, Andrei Alexandrescu
wrote:
On 06/26/2016 02:07 PM, ketmar wrote:
On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu
wrote:
See the recent thread "DbI checked integral". Saturation is a
direct
goal, and you should be able to optimize operations
On Saturday, 25 June 2016 at 16:05:08 UTC, ZombineDev wrote:
Overall DMD completes mandel.b for 75.5% of the time of the
previous version, LDC for 62.6% and GDC for 88.1%. The code is
64.9% of the original (in terms of LOC).
This is what I love: less code with more performance. Great work
on
Is there an AWS library in the works for D? It's seriously the
main blocker for me to push adoption of the language internally.
If not, I can try to invest time into making one, but I could use
help.
(fyi, there's one in the works for Rust:
https://github.com/rusoto/rusoto)
On Sunday, 26 June 2016 at 22:34:29 UTC, Andrei Alexandrescu
wrote:
What is some good literature to look at for SIMD saturation
arithmetic? -- Andrei
sorry, i don't know. for me it was intel cpu manuals. certainly
not even a good way to learn the things.
On 6/26/2016 3:32 PM, Walter Bright wrote:
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any type whatsoever
'template';
Still adding D features, I see!
Reading:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0127r1.html
shows it is s
On 6/26/2016 6:13 AM, Robert burner Schadek wrote:
It would be awesome if you would create that process model in the wiki and at it
to your action list
http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List
It's a wiki, feel free to add it.
On 06/26/2016 02:07 PM, ketmar wrote:
On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu wrote:
See the recent thread "DbI checked integral". Saturation is a direct
goal, and you should be able to optimize operations for each type by
defining relatively small hooks.
alas, it is compl
On 6/26/2016 10:18 AM, Enamex wrote:
- template arguments that accept constant values of any type whatsoever
'template';
Still adding D features, I see!
On Sunday, 26 June 2016 at 21:14:16 UTC, QAston wrote:
Also - metaprogramming. You don't know the control flow of
whatever you may be printing in a mixin, or having as a
parameter in a template. Making such code even more difficult
to analyze.
Also, this couples runtime control flow with cond
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
Please no. I'd argue that this brings more confusion than
readibility. Imagine reading more complicated code with this. You
have to
On Sunday, 26 June 2016 at 17:18:48 UTC, Enamex wrote:
- specified order of evaluation for function calls and any
syntax with arguments (including built-in operators on
primitive types).
But not on the arguments, as that will harm optimization too
much. I believe this change was triggered b
On Sunday, 26 June 2016 at 18:16:32 UTC, Jack Stouffer wrote:
Please be excited for modules, coming out three years from now
(plus implementation time).
It is actually a good thing that they delay modules. It is
difficult to get right, but it is on a separate track so it can
come before C++Ne
On Sunday, 26 June 2016 at 17:18:48 UTC, Enamex wrote:
https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/
Added stuff like:
- a very limited destructuring syntax (structured bindings)
(use case is for tuples; but likely to use a new reserved
funct
On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu
wrote:
See the recent thread "DbI checked integral". Saturation is a
direct goal, and you should be able to optimize operations for
each type by defining relatively small hooks.
alas, it is completely inappropriate for any computatio
On 26 June 2016 at 14:33, Timon Gehr via Digitalmars-d
wrote:
> On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote:
>>
>> Old codegen:
>>
>> _base = *(getBase());
>> _lwr = getLowerBound(_base.length);
>> _upr = getUpperBound(_base.length);
>> r = {.length=(_upr - _lwr), .ptr=_base.ptr + _lw
https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/
Added stuff like:
- a very limited destructuring syntax (structured bindings)
(use case is for tuples; but likely to use a new reserved
function name for general struct destructuring (like 'get<>()
Robert burner Schadek wrote:
> On Saturday, 25 June 2016 at 21:32:00 UTC, Andrei Alexandrescu
> wrote:
>> So it stands to reason that if you want to design a checked
>> integral types offering a variety of checking policies, one
>> point in the design space that needs to be attainable is "no
>
On Sunday, 26 June 2016 at 14:48:00 UTC, Guillaume Chatelet wrote:
Johan I saw you created a few bugs for C++ name mangling. Can
you assigne the one for Linux to me. I'm redesigning the
algorithm and I need as many corner cases as possible.
Note: I'm only touching the 'Linux' C++ mangling code
On Sunday, 26 June 2016 at 09:28:19 UTC, Johan Engelen wrote:
On Sunday, 26 June 2016 at 07:51:16 UTC, Guillaume Chatelet
wrote:
This is fine in the case where E is a D interface because of
reference semantics: it should be passed by pointer.
But, in the case where an extern(C++) function ca
On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote:
Andrei identified a key blocker for D adoption is the
incomplete implementation of @safe. I'm working on the compiler
end. But Phobos has a lot of code that is pointlessly not
@safe, making it frustrating to write @safe code that c
On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu
wrote:
On 6/26/16 9:47 AM, Manu via Digitalmars-d wrote:
Hi people. I've been working on this colour library when I
have free
time (almost never!), and I want to work on blending/filtering
functions, but that work is kinda blocked by
On 6/26/16 9:47 AM, Manu via Digitalmars-d wrote:
Hi people. I've been working on this colour library when I have free
time (almost never!), and I want to work on blending/filtering
functions, but that work is kinda blocked by saturating arithmetic
logic.
I started working on a saturating integer
Hi people. I've been working on this colour library when I have free
time (almost never!), and I want to work on blending/filtering
functions, but that work is kinda blocked by saturating arithmetic
logic.
I started working on a saturating integer library a few times, but
it's much a much bigger jo
It would be awesome if you would create that process model in the
wiki and at it to your action list
http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List
So it does not get lost and people can find it.
On Saturday, 25 June 2016 at 21:32:00 UTC, Andrei Alexandrescu
wrote:
So it stands to reason that if you want to design a checked
integral types offering a variety of checking policies, one
point in the design space that needs to be attainable is "no
checks at all". Then the syntactic shell wor
On 24/06/16 19:26, maik klein wrote:
https://maikklein.github.io/post/cmp-rust-d/
https://www.reddit.com/r/programming/comments/4po2j5/a_comparison_between_rust_and_d/
It's possible in D to collect multiple functions for one set of
constraints using a template:
template Foo(T) if (is(T : in
On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote:
> Evaluation order should be strictly left-to-right. DMD and GDC
get it wrong
> here.
>
It is evaluated left-to-right. getBase() -> getLowerBound() ->
getUpperBound().
Ah, I see what you mean. I think you ma
On Sunday, 26 June 2016 at 00:54:04 UTC, Guillaume Boucher wrote:
If division truncates towards negative infinity, the remainder
will always be nonegative (in case of a positive divisor).
Or even better, use euclidean division, then the reminder always
remains non-negative:
https://en.wikipe
On Sunday, 26 June 2016 at 08:08:58 UTC, Iain Buclaw wrote:
Now when creating temporaries of references, the reference is
stabilized instead.
New codegen:
*(_ptr = getBase());
_lwr = getLowerBound(_ptr.length);
_upr = getUpperBound(_ptr.length);
r = {.length=(_upr - _lwr), .ptr=_ptr.ptr + _lwr
On Sunday, 26 June 2016 at 07:51:16 UTC, Guillaume Chatelet wrote:
This is fine in the case where E is a D interface because of
reference semantics: it should be passed by pointer.
But, in the case where an extern(C++) function calls an
extern(C++) type should it be value semantic - as it is
On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote:
Andrei identified a key blocker for D adoption is the
incomplete implementation of @safe. I'm working on the compiler
end. But Phobos has a lot of code that is pointlessly not
@safe, making it frustrating to write @safe code that c
On 26 June 2016 at 09:36, Iain Buclaw wrote:
> On 26 June 2016 at 03:30, Timon Gehr via Digitalmars-d
> wrote:
> > On 17.06.2016 21:59, kinke wrote:
> >>
> >>
> >> Most interesting IMO though is the question when the slicee's pointer is
> >> to be loaded. This is only relevant if the base is an
This is currently part of the dmd test suite [1]:
extern (C++) interface E
{
int bar(int i, int j, int k);
}
extern (C++) int callE(E);
static assert (callE.mangleof == "_Z5callEP1E");
The last line checks that callE() will pass its argument by
pointer.
This is fine in the case where
On 26 June 2016 at 03:30, Timon Gehr via Digitalmars-d
wrote:
> On 17.06.2016 21:59, kinke wrote:
>>
>>
>> Most interesting IMO though is the question when the slicee's pointer is
>> to be loaded. This is only relevant if the base is an lvalue and may
>> therefore be modified when evaluating the b
On Sunday, 26 June 2016 at 05:28:53 UTC, Shachar Shemesh wrote:
So, we can do it your way. This would mean:
1. Losing performance for every division and modulus that
*might* be negative
I don't think the performance issue is relevant. It was relevant
when it was left implementation defined in
On Sunday, 26 June 2016 at 05:44:53 UTC, deadalnix wrote:
Except for mathematica, these are all irrelevant. The claim is
that programming languages and CPU define % in some way, not
that mathematician do it the same way.
Well, the CPU does not define it. It is just that C botchered it
by leav
Unsure of exactly how to communicate this one, so posting here.
Compilation of https://github.com/dcarp/asynchronous.
Using 'dub --verbose build' produces:
dmd -lib
-of.dub/build/library-debug-linux.posix-x86_64-dmd_2071-7450FEAE5605F646044C35441C27D67E/libasynchronous.a
-debug -g -w -version=C
52 matches
Mail list logo
