On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
Destroy!
Extend rationale: could be application to templates and using
with CTFE.
"inferred" is not consistent. As I understand inferred applies to
templates only. And default value is so called
inferred_or_system. So it is infe
On Wednesday, 26 July 2017 at 09:46:45 UTC, Timon Gehr wrote:
readln.split.fold!((stack,op){
switch(op){
static foreach(c;"+-*/") case [c]:
return stack[0..$-2]~mixin("stack[$-2] "~c~"
stack[$-1]");
default: return stack~op.to!real;
On Wednesday, 19 July 2017 at 15:41:18 UTC, Jack Stouffer wrote:
On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
Thoughts on this sort of feature?
To be frank, I don't think that helping the programmer reduce
the line count in their program by one line is worth further
complicatin
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:
On 07/19/2017 03:30 PM, sontung wrote:
So I was thinking of some sort of syntax like this:
if(int i = someFunc(); i >= 0)
{
// use i
}
Thoughts on this sort of feature?
I'd prefer a new variant of `with`:
---
Just another idea.
So as I understand
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#owning-containers
there is problem with safe assignment of slices. But the problem
is actual only if some element has scope ref.
1. Lets introduce type state "referred".
```
//safe code
RCSlice!int
On Tuesday, 13 December 2016 at 22:33:24 UTC, Andrei Alexandrescu
wrote:
Destroy.
https://github.com/dlang/DIPs/pull/51/files
Andrei
How about something like Haskells "where" to allow any set of
pre-declaration just for one declaration:
with
{
import ...;
alias Result = ...;
}
Result func
On Tuesday, 8 November 2016 at 16:40:31 UTC, Nick Sabalausky
wrote:
On 11/05/2016 11:48 AM, Marc Schütz wrote:
On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch
wrote:
I recently lost 3 days of work because of my git-skills.
Unless you haven't committed your work yet, almost everythi
On Friday, 9 September 2016 at 15:28:55 UTC, Stefan Koch wrote:
On Friday, 9 September 2016 at 15:08:26 UTC, Iakh wrote:
On Friday, 9 September 2016 at 07:56:04 UTC, Stefan Koch wrote:
I was thinking on adding "opaque" attribute for template
arguments
to force template to forget some informat
On Friday, 9 September 2016 at 07:56:04 UTC, Stefan Koch wrote:
I was thinking on adding "opaque" attribute for template arguments
to force template to forget some information about type.
E.g if you use
class A(opaque T) {...}
you can use only pointers/references to T.
Probably compiler could
On Sunday, 29 May 2016 at 11:16:57 UTC, Dicebot wrote:
On 05/28/2016 09:58 PM, Iakh wrote:
Yeah. It doesn't capture any context. But once it does it
would be an error.
Custom allocators are not very suitable for things like
closures because of undefined lifetime. Even if it was allowed
to re
On Thursday, 26 May 2016 at 21:10:30 UTC, bpr wrote:
On Thursday, 26 May 2016 at 18:53:35 UTC, Iakh wrote:
Functions with lambdas cannot be @nogc as far as they
allocates closures.
Counterexample:
// Note that this is NOT a good way to do numerical quadrature!
double integrate(scope double
On Friday, 27 May 2016 at 10:34:38 UTC, Kagamin wrote:
On Thursday, 26 May 2016 at 18:53:35 UTC, Iakh wrote:
void g() @nogc
{
catch scope(void);
int[N] arr = [/*...*/];
arr[].sort!((a, b) => a > b);
}
This compiles just fine and doesn't allocate:
void g() @nogc
{
int[2] arr = [
Functions with lambdas cannot be @nogc as far as they allocates
closures.
And the way lambdas works is completely different from C++ way.
In D using
lambda we define how some part of "stack" frame allocates. So in
some aspect
closure allocation is property of a function. So we need a way
to tel
On Friday, 13 May 2016 at 01:00:54 UTC, Walter Bright wrote:
On 5/12/2016 5:47 PM, Jack Stouffer wrote:
D is much less popular now than was Python at the time, and
Python 2 problems
were more straight forward than the auto-decoding problem.
You'll need a very
clear migration path, years long d
On Sunday, 8 May 2016 at 10:24:12 UTC, Mithun Hunsur wrote:
Hi all,
I was discussing this with Stefan Koch and a few other people
at DConf - would it be possible to have a compiler switch for
outputting the complete source file after the mixins have been
expanded, similar to gcc -E?
I think
Recent discussion about inout cause some thoughts on this. And
they bring me to opaque
types. We could put a type into temlate but there is no direct
way to limit information
about this type inside template.
There is no way to say that template uses only part info about
type or don't use it
a
On Thursday, 31 March 2016 at 08:23:45 UTC, Martin Nowak wrote:
I'm currently working on a templated arrayop implementation
(using RPN
to encode ASTs).
So far things worked out great, but now I got stuck b/c
apparently none
of the D compilers has a working SIMD implementation (maybe GDC
has bu
On Thursday, 24 March 2016 at 19:30:46 UTC, Temtaime wrote:
And what's a problem with unions by the way ? By specs,
currently it's forbidden to have union with pointers and value
types.
It's forbidden in @safe
On Monday, 29 February 2016 at 13:31:11 UTC, Atila Neves wrote:
http://forum.dlang.org/post/tgnxocozkurfvmxqo...@forum.dlang.org
Atila
If you about this:
http://forum.dlang.org/post/eejiauievypbfifky...@forum.dlang.org
On Wednesday, 29 July 2015 at 06:05:37 UTC, Kagamin wrote:
On Tuesday, 2
On Monday, 29 February 2016 at 13:31:11 UTC, Atila Neves wrote:
I'm not familiar with github so i can't see why it was rejected
besides auto testing tools (Looks like it's just outdated)
http://forum.dlang.org/post/tgnxocozkurfvmxqo...@forum.dlang.org
Atila
I didn't get the point.
But I cou
On Monday, 29 February 2016 at 11:13:18 UTC, Atila Neves wrote:
On Saturday, 27 February 2016 at 13:35:30 UTC, Iakh wrote:
There was discussion and proposal to extend D with static
inheritance:
http://forum.dlang.org/thread/jwzxngccuwwizyivp...@forum.dlang.org
But it could be done just with mi
On Saturday, 27 February 2016 at 20:51:22 UTC, Chris Wright wrote:
On Sat, 27 Feb 2016 19:45:58 +, Iakh wrote:
It is hard to pass all params to the mixin such as file, line
and additional params for concept:
Maybe we need file and line number __traits.
Nice idea.
I am also voting for fu
On Saturday, 27 February 2016 at 18:14:25 UTC, Chris Wright wrote:
On Sat, 27 Feb 2016 13:35:30 +, Iakh wrote:
Looks good. I'd prefer to have just the mixin or just the
attribute -- the latter being tricky just now.
Agree.
It'd be just as easy to make it:
struct Range {
mixin ensureCo
There was discussion and proposal to extend D with static
inheritance:
http://forum.dlang.org/thread/jwzxngccuwwizyivp...@forum.dlang.org
But it could be done just with mixins, UDAs and some rewriting of
predicates.
Exaple:
@concept!isInputRange()
struct Range
{
mixin checkConcepts;
i
On Thursday, 25 February 2016 at 09:11:58 UTC, Atila Neves wrote:
On Thursday, 25 February 2016 at 01:57:37 UTC, Iakh wrote:
On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
[...]
It could be better to extend UDA with checking and diagnostic
functions
@IsInputRange
struct myR
On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
From the discussion here:
http://forum.dlang.org/post/tgnxocozkurfvmxqo...@forum.dlang.org, I thought a library solution would do to fix the issue of getting decent error messages when a type fails to satisfy a template constraint tha
On Thursday, 18 February 2016 at 22:46:04 UTC, Walter Bright
wrote:
On 2/18/2016 10:22 AM, Timon Gehr wrote:
He wanted to embed a mutable reference count literally within
a const object.
Not a headconst object.
I know. I pointed out how it could be done in a way to achieve
the same effect.
On Saturday, 13 February 2016 at 21:12:10 UTC, Andrei
Alexandrescu wrote:
On 02/13/2016 03:07 PM, Iakh wrote:
So you can use metadata only with global allocators,
until you don't need to save ref to the allocator.
Well you can use other allocators if you save them so you have
them available f
On Friday, 12 February 2016 at 19:12:48 UTC, Andrei Alexandrescu
wrote:
https://github.com/D-Programming-Language/phobos/pull/3991
A short while ago Dicebot discussed the notion of using the
allocator to store the reference count of objects (and
generally metadata). The allocator seems to be a
On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright
wrote:
@safe protects you from segmentation faults and reading and
writing outside an allocated segment of memory. With array
casts, @safety is assured
Yes, @safe protects from direct cast to/from ref types but there
still is a trick
On Wednesday, 10 February 2016 at 08:49:21 UTC, w0rp wrote:
On Tuesday, 9 February 2016 at 21:20:53 UTC, Iakh wrote:
https://dlang.org/spec/function.html#function-safety
Current definition of safety doesn't mention cast of arrays.
I think this should be addressed, as if you can't cast between
https://dlang.org/spec/function.html#function-safety
Current definition of safety doesn't mention cast of arrays.
E.g this code allowed by DMD
int[] f(void[] a) @safe pure
{
return cast(int[])a;
}
But same void* to int* cast is forbidden.
So we need some rules for dynamic arrays casting.
e.g
On Tuesday, 9 February 2016 at 16:32:07 UTC, Steven Schveighoffer
wrote:
I think the rules at the moment are that the compiler allows
implicit conversion if the return value could not have come
from any of the parameters. But what it may not consider is if
the parameters could be return values
On Monday, 8 February 2016 at 21:48:30 UTC, Jonathan M Davis
wrote:
that right now, but clearly, what it currently has is buggy,
Yeah. Looks like it just traverse params's AST and search for
exactly match with ReturnType.
The code with replaced (void, int) with (class A, class B : A)
behaves
On Monday, 8 February 2016 at 20:43:23 UTC, Jonathan M Davis
wrote:
in a bug report should be sufficient to show the bug, even
without the rest of what you're doing.
In general, it should be impossible for member functions to be
considered strongly pure unless they're marked as immutable,
On Monday, 8 February 2016 at 19:33:54 UTC, Jesse Phillips wrote:
I'm pretty sure this is not safe. Works, but not safe. You
So it is bug?
import std.stdio;
struct S
{
void[] arr;
auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
int[] b = (cast(int[])s.arr);
writeln(a);
b[0] = 1;
writeln(a);
}
http://dpas
On Sunday, 7 February 2016 at 05:18:39 UTC, Steven Schveighoffer
wrote:
4 testexpansion 0x00010fb5dbec pure
@safe void
testexpansion.s!(testexpansion.s!(testexpansion.s!(testexpansion.s!(testexpansion.s!
Why "bad" foo is void?
Is there a better way we should be do
On Sunday, 7 February 2016 at 14:00:24 UTC, Iakh wrote:
Explanations:
As far as "immutable" transitive:
--
immutable RCString str;
*str.counter++; // Impossible/error/undefined behavior(with const
cast)
--
Language defines immutable to do some optimizations based on true
constness of st
Is it hard to make pointee data mutable?
E.g. if have:
--
struct RCString
{
private char[] data;
private @mutable int* counter;
}
--
So for optimiser (in case of immutable) this looks like
--
struct RCString
{
private char[] data;
private @mutable void* counter; // poin
I'm thinking of implementation std.simd in fashion different to
https://github.com/TurkeyMan/simd
since it looks dead and too sophisticated.
My proposal is:
- std.simd - processor independent intrinsics and some high
level stuff.
You only depend on different sizes of SIMD vector.
On Thursday, 21 January 2016 at 14:04:58 UTC, Andrei Alexandrescu
wrote:
On 01/21/2016 08:42 AM, Era Scarecrow wrote:
I'd almost say lowestCount and highestCount would almost be
better, but
i am not sure.
minCount is already a given. -- Andrei
countMost!less and posMost!less
On Friday, 30 October 2015 at 21:33:25 UTC, Andrei Alexandrescu
wrote:
Could you please take a look at GCC's generated code and
implementation of memchr? -- Andrei
So i did. I rewrite code to do main work in cacheLineSize chunks.
And this
is what GLIBC version do.
So main loop looks this:
--
On Friday, 30 October 2015 at 21:33:25 UTC, Andrei Alexandrescu
wrote:
Could you please take a look at GCC's generated code and
implementation of memchr? -- Andrei
Copy-and-paste from glibc's memchr(runGLibC) gaves the result
below.
-
Naive: 21.4 TickDuration(132485705)
SIMD:
On Saturday, 31 October 2015 at 08:37:23 UTC, rsw0x wrote:
I got it to 1.5 the running time of C using SSE2 but couldn't
Can you share your solution?
On Friday, 30 October 2015 at 21:33:25 UTC, Andrei Alexandrescu
wrote:
Could you please take a look at GCC's generated code and
implementation of memchr? -- Andrei
glibc uses something like pseudo-SIMD with ordinal x86
instructions (XOR magic, etc).
Deap comarison I left for next time :)
I continue to play with SIMD. So I was trying to use std.simd
But it has lots of thing to be implemented. And I also gave up
with
core.simd.__simd due to problems with PMOVMSKB instruction (it
is not implemented).
Today I was playing with memchr for gdc:
memchr: http://www.cplusplus.com/refer
On Monday, 26 October 2015 at 12:35:39 UTC, Don wrote:
You need to be very careful with doing benchmarks on tiny test
cases, they can be very misleading.
Can you advice some reading about benchmark?
On Monday, 26 October 2015 at 15:03:12 UTC, Iakh wrote:
(Binary)Searching in large sorted continuous array e. g. 1 MB
of bytes
1 MB = 2 ^^ 20 bytes
Imagine 4 binary levels pass in 4 ticks. So 20 levels in 20
ticks. With SIMD last 4 levels would be done in 2 or 3 ticks.
For 20 levels 18 - 19 t
On Monday, 26 October 2015 at 11:47:56 UTC, Andrei Alexandrescu
wrote:
On 10/26/2015 05:48 AM, Iakh wrote:
On Monday, 26 October 2015 at 00:00:45 UTC, anonymous wrote:
runBinary calls naiveIndexOf. You're not testing
binaryIndexOf.
You are right.
This is fixed example:
http://dpaste.dzfl.pl/f
On Monday, 26 October 2015 at 09:49:00 UTC, Iakh wrote:
On Monday, 26 October 2015 at 00:00:45 UTC, anonymous wrote:
runBinary calls naiveIndexOf. You're not testing binaryIndexOf.
You are right.
This is fixed example:
http://dpaste.dzfl.pl/f7a54b789a21
and results at dpaste.dzfl.pl:
-
SI
On Monday, 26 October 2015 at 00:00:45 UTC, anonymous wrote:
runBinary calls naiveIndexOf. You're not testing binaryIndexOf.
You are right.
This is fixed example:
http://dpaste.dzfl.pl/f7a54b789a21
and results at dpaste.dzfl.pl:
-
SIMD: TickDuration(151000)
Binary: TickDuration(255000)
N
On Sunday, 25 October 2015 at 21:13:56 UTC, Andrei Alexandrescu
wrote:
[...]
This is compelling but needs a bit of work to integrate. Care
to work on a PR that makes std.algorithm use it? Thanks! --
Andrei
First of all I need sort of investigation about PRs and
std.algorithm. But in general
On Sunday, 25 October 2015 at 22:17:58 UTC, Matthias Bentrup
wrote:
On Sunday, 25 October 2015 at 19:37:32 UTC, Iakh wrote:
Is it optimal and how do you implement this stuf?
I think it's better to use PMOVMSKB to avoid storing the
PCMPEQB result in memory and you need only one BSF instructio
On Wednesday, 23 September 2015 at 09:58:39 UTC, Marco Leise
wrote:
Am Tue, 22 Sep 2015 16:36:40 +
schrieb Iakh :
[...]
Implementatation of SIMD find algorithm:
http://forum.dlang.org/post/hwjbyqnovwbyibjus...@forum.dlang.org
Here is my implementatation of SIMD find. Function returns index
of ubyte in static 16 byte array with unique values.
--
immutable size_t ArraySize = 16;
int simdIndexOf(ubyte niddle, ref const ubyte[ArraySize] haystack)
{
ubyte16 arr;
arr.array = haystack[];
ubyte16 niddles;
On Wednesday, 23 September 2015 at 09:58:39 UTC, Marco Leise
wrote:
Am Tue, 22 Sep 2015 16:36:40 +
schrieb Iakh :
[...]
thanks for the workaround(s)
On Tuesday, 22 September 2015 at 20:10:36 UTC, David Nadlinger
wrote:
On Tuesday, 22 September 2015 at 19:45:33 UTC, Iakh wrote:
Your solution is platform dependent, isn't it?
Platform-dependent in what way? Yes, the intrinsic for PMOVMSKB
is obviously x86-only.
core.simd XMM enum has comm
On Tuesday, 22 September 2015 at 17:46:32 UTC, David Nadlinger
wrote:
On Tuesday, 22 September 2015 at 16:36:42 UTC, Iakh wrote:
__mm_movemask_epi a cornerstone of the topic currently not
implemented/not supported in D :(
AFAIK it has irregular result format
From ldc.gccbuiltins_x86:
int __b
On Tuesday, 22 September 2015 at 13:06:39 UTC, Andrei
Alexandrescu wrote:
A paper I found interesting:
http://openproceedings.org/EDBT/2014/paper_107.pdf -- Andrei
__mm_movemask_epi a cornerstone of the topic currently not
implemented/not supported in D :(
AFAIK it has irregular result format
Hi!
There is my pre alpha implementation of sparse array
based on adaptive radix tree:
https://github.com/Iakh/d-art-containers
It is based on this article
http://www-db.in.tum.de/~leis/papers/ART.pdf
And here is general information about radix tree:
https://en.wikipedia.org/wiki/Radix_tree
Rad
61 matches
Mail list logo
