passing static arrays to each! with a ref param [Re: Why can't static arrays be sorted?]

[Jon Degenhardt via Digitalmars-d-learn]

On Monday, 10 October 2016 at 16:46:55 UTC, Jonathan M Davis 
wrote:
On Monday, October 10, 2016 16:29:41 TheGag96 via 
Digitalmars-d-learn wrote:
On Saturday, 8 October 2016 at 21:14:43 UTC, Jon Degenhardt 
wrote:
> This distinction is a bit on the nuanced side. Is it 
> behaving as it should?

>
> --Jon

I think so? It's not being modified in the second case because 
the array is being passed by value... "x" there is a reference 
to an element of the copy created to be passed to each(). I 
assume there's a good reason why ranges in general are passed 
by value into these functions -- except in this one case, the 
stuff inside range types copied when passed by value won't be 
whole arrays, I'm guessing.


Whether it's by value depends entirely on the type of the 
range. They're passed around, and copying them has whatever 
semantics it has. In most cases, it copies the state of the 
range but doesn't copy all of the elements (e.g. that's what 
happens with a dynamic array, since it gets sliced). But if a 
range is a class, then it's definitely a reference type.  The 
only way to properly save the state of a range is to call save.


But passing by ref would make no sense at all with input 
ranges. It would completely kill chaining them. Almost all 
range-based functions return rvalues.


- Jonathan M Davis


The example I gave uses ref parameters. On the surface it would 
seem reasonable to that passing a static array by ref would allow 
it to be modified, without having to slice it first. The 
documentation says:


// If the range supports it, the value can be mutated in place
   arr.each!((ref n) => n++);
   assert(arr == [1, 2, 3, 4, 5]);

but, 'arr' is a dynamic array, so technically it's not describing 
a static array (the opApply case).


Expanding the example, using foreach with ref parameters will 
modify the static array in place, without slicing it. I would 
have expected each! with a ref parameter to behave the same.


At a minimum this could be better documented, but it may also be 
a bug.


Example:

T increment(T)(ref T x) { return x++; }

void main()
{
import std.algorithm : each;

int[] dynamicArray = [1, 2, 3, 4, 5];
int[5] staticArray = [1, 2, 3, 4, 5];

dynamicArray.each!(x => x++); // Dynamic array by 
value

assert(dynamicArray == [1, 2, 3, 4, 5]);  // ==> Not modified

dynamicArray.each!((ref x) => x++);   // Dynamic array by 
ref

assert(dynamicArray == [2, 3, 4, 5, 6]);  // ==> Modified

staticArray[].each!((ref x) => x++);  // Slice of static 
array, by ref

assert(staticArray == [2, 3, 4, 5, 6]);   // ==> Modified

staticArray.each!((ref x) => x++);// Static array by 
ref

assert(staticArray == [2, 3, 4, 5, 6]);   // ==> Not Modified

/* Similar to above, using foreach and ref params. */
foreach (ref x; dynamicArray) x.increment;
assert(dynamicArray == [3, 4, 5, 6, 7]);  // Dynamic array => 
Modified


foreach (ref x; staticArray[]) x.increment;
assert(staticArray == [3, 4, 5, 6, 7]);   // Static array 
slice => Modified


foreach (ref x; staticArray) x.increment;
assert(staticArray == [4, 5, 6, 7, 8]);   // Static array => 
Modified

}

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 03:58:59 UTC, Andrei Alexandrescu 
wrote:

On 10/10/16 11:00 PM, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei 
Alexandrescu wrote:
That looks good. I'm just worried about the jump forward - 
ideally the
case c < 127 would simply entail a quick return. I tried a 
fix, but it
didn't do what I wanted in ldc. We shouldn't assert(0) if 
wrong - just
skip one byte. Also, are we right to not worry about 5- and 
6-byte
sequences? The docs keep on threatening with it, and then 
immediately

mention those are not valid.

[ ... ]

Andrei



If you want to skip a byte it's easy to do as well.

void popFront3(ref char[] s) @trusted pure nothrow {
   immutable c = s[0];
   uint char_length = 1;
   if (c < 127)
   {
   Lend :
 s = s.ptr[char_length .. s.length];
   } else {
 if ((c & b01100_) == 0b1000_)
 {
   //just skip one in case this is not the beginning of a 
code-point

char
   goto Lend;
 }
 if (c < 192)
 {
   char_length = 2;
   goto Lend;
 }
 if (c < 240)
 {
   char_length = 3;
   goto Lend;
 }
 if (c < 248)
 {
   char_length = 4;
   goto Lend;
 }
   }
 }



Affirmative. That's identical to the code in "[ ... ]" :o). 
Generated code still does a jmp forward though. -- Andrei


It was not identical.
((c & b01100_) == 0b1000_))
Can be true in all of the 3 following cases.
If we do not do a jmp to return here, we cannot guarantee that we 
will not skip over the next valid char.

Thereby corrupting already corrupt strings even more.

For best performance we need to leave the gotos in there.

Re: Linker Error: undefined reference to `internal'

[Walter Bright via Digitalmars-d]

On 10/10/2016 3:20 PM, jython234 wrote:

I've tracked it down to two lines (which are the same):

private SyncLock lock = new SyncLock();

SyncLock is just an empty class which I use to construct objects for use in
"synchronized" blocks (not sure if this is the right way to do this). Apparently
if I move the initialization to the constructor there are no linker errors.


You can use obj2asm to examine the object files to see what is different between 
the two cases.

Re: Can you shrink it further?

[Andrei Alexandrescu via Digitalmars-d]

On 10/10/16 11:00 PM, Stefan Koch wrote:

On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei Alexandrescu wrote:

That looks good. I'm just worried about the jump forward - ideally the
case c < 127 would simply entail a quick return. I tried a fix, but it
didn't do what I wanted in ldc. We shouldn't assert(0) if wrong - just
skip one byte. Also, are we right to not worry about 5- and 6-byte
sequences? The docs keep on threatening with it, and then immediately
mention those are not valid.

[ ... ]

Andrei



If you want to skip a byte it's easy to do as well.

void popFront3(ref char[] s) @trusted pure nothrow {
   immutable c = s[0];
   uint char_length = 1;
   if (c < 127)
   {
   Lend :
 s = s.ptr[char_length .. s.length];
   } else {
 if ((c & b01100_) == 0b1000_)
 {
   //just skip one in case this is not the beginning of a code-point
char
   goto Lend;
 }
 if (c < 192)
 {
   char_length = 2;
   goto Lend;
 }
 if (c < 240)
 {
   char_length = 3;
   goto Lend;
 }
 if (c < 248)
 {
   char_length = 4;
   goto Lend;
 }
   }
 }



Affirmative. That's identical to the code in "[ ... ]" :o). Generated 
code still does a jmp forward though. -- Andrei

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 03:18:24 UTC, Lurker wrote:


Pardon me asking, but why all these gotos instead of else ifs:

  if (c < 192)
  {
char_length = 2;
  }
  else if (c < 240)
  {
char_length = 3;
  } else if (...) {
  }

Does it have any effect on generated code (I don't think it 
should)?


No it does not.
I wrote the gotos because that is how I am used to thinking about 
code.

If else should work fine here.

Re: Batch operations

[rikki cattermole via Digitalmars-d]

On 11/10/2016 4:20 PM, Stefan Koch wrote:

On Tuesday, 11 October 2016 at 03:05:12 UTC, Nicholas Wilson wrote:

Splitting this from the colour
thread(https://forum.dlang.org/thread/mailman.961.1475765646.2994.digitalmar...@puremagic.com?page=1).


[...]


This will bloat like hell.
The best way would be to provide special Range-Definitions for those.
Such as
T[4] Front4 ()
or popFront4


We would also want 2, 8 and 16 for SIMD reasons.

Re: Batch operations

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 03:05:12 UTC, Nicholas Wilson 
wrote:
Splitting this from the colour 
thread(https://forum.dlang.org/thread/mailman.961.1475765646.2994.digitalmar...@puremagic.com?page=1).


[...]


This will bloat like hell.
The best way would be to provide special Range-Definitions for 
those.

Such as
T[4] Front4 ()
or popFront4

Re: Can you shrink it further?

[Lurker via Digitalmars-d]

On Tuesday, 11 October 2016 at 03:00:45 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei 
Alexandrescu wrote:
That looks good. I'm just worried about the jump forward - 
ideally the case c < 127 would simply entail a quick return. I 
tried a fix, but it didn't do what I wanted in ldc. We 
shouldn't assert(0) if wrong - just skip one byte. Also, are 
we right to not worry about 5- and 6-byte sequences? The docs 
keep on threatening with it, and then immediately mention 
those are not valid.


[ ... ]

Andrei



If you want to skip a byte it's easy to do as well.

void popFront3(ref char[] s) @trusted pure nothrow {
   immutable c = s[0];
   uint char_length = 1;
   if (c < 127)
   {
   Lend :
 s = s.ptr[char_length .. s.length];
   } else {
 if ((c & b01100_) == 0b1000_)
 {
   //just skip one in case this is not the beginning of a 
code-point char

   goto Lend;
 }
 if (c < 192)
 {
   char_length = 2;
   goto Lend;
 }
 if (c < 240)
 {
   char_length = 3;
   goto Lend;
 }
 if (c < 248)
 {
   char_length = 4;
   goto Lend;
 }
   }
 }


Pardon me asking, but why all these gotos instead of else ifs:

  if (c < 192)
  {
char_length = 2;
  }
  else if (c < 240)
  {
char_length = 3;
  } else if (...) {
  }

Does it have any effect on generated code (I don't think it 
should)?

Batch operations

[Nicholas Wilson via Digitalmars-d]

Splitting this from the colour 
thread(https://forum.dlang.org/thread/mailman.961.1475765646.2994.digitalmar...@puremagic.com?page=1).


So currently D does not have a way to express batch operations 
that work seamlessly with normal ranges.


Manu suggested to use the array operation syntax. I suggest 
something along the lines of the following, forwarding any 
operations to the static array.


struct InBatchesOfN(size_t N,R) if( N!=0 && isInputRange!R
 && 
hasLength!R)

{
R r;
static struct Batch
{
ElementType!(R)[N] elements;
auto get() { return elements[]; }
alias get this;
Batch opBinary(string op)(Batch rhs) 
if(hasOperator!(ElementType!(R),op))

{
Batch b;
foreach(i; iota(N)) mixin("b.elements[i] = 
elememts[i] "~op~" rhs.elements[i]");

return b;
}
//repeat for opUnary,opOpAssign,opDispatch etc...
}
Batch batch;
this(R _r)
{
// could have overloads where undefined elements == 
ElementType!(R).init

assert(_r.length % N ==0);
r = _r;
foreach( i; iota(N))
{
batch[i] = r.front;
r.popFront;
}
}
bool empty() { return r.empty; }
auto front() { return batch; }
void popFront()
{
foreach(i; iota(N))
{
batch.elements[i] = r.front;
r.popFront;
}
}
}

auto inBatchesOf(size_t N,R)(R r)
{
return InBatchesOfN(r);
}

Thoughts?

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei Alexandrescu 
wrote:
That looks good. I'm just worried about the jump forward - 
ideally the case c < 127 would simply entail a quick return. I 
tried a fix, but it didn't do what I wanted in ldc. We 
shouldn't assert(0) if wrong - just skip one byte. Also, are we 
right to not worry about 5- and 6-byte sequences? The docs keep 
on threatening with it, and then immediately mention those are 
not valid.


[ ... ]

Andrei



If you want to skip a byte it's easy to do as well.

void popFront3(ref char[] s) @trusted pure nothrow {
   immutable c = s[0];
   uint char_length = 1;
   if (c < 127)
   {
   Lend :
 s = s.ptr[char_length .. s.length];
   } else {
 if ((c & b01100_) == 0b1000_)
 {
   //just skip one in case this is not the beginning of a 
code-point char

   goto Lend;
 }
 if (c < 192)
 {
   char_length = 2;
   goto Lend;
 }
 if (c < 240)
 {
   char_length = 3;
   goto Lend;
 }
 if (c < 248)
 {
   char_length = 4;
   goto Lend;
 }
   }
 }

Re: Can you shrink it further?

[Andrei Alexandrescu via Digitalmars-d]

That looks good. I'm just worried about the jump forward - ideally the 
case c < 127 would simply entail a quick return. I tried a fix, but it 
didn't do what I wanted in ldc. We shouldn't assert(0) if wrong - just 
skip one byte. Also, are we right to not worry about 5- and 6-byte 
sequences? The docs keep on threatening with it, and then immediately 
mention those are not valid.


void popFront3(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  uint char_length = 1;
  if (c < 127)
  {
  Lend :
s = s.ptr[char_length .. s.length];
  } else {
if (c < 192)
{
  char_length = 2;
  goto Lend;
}
if (c < 240) {
  char_length = 3;
  goto Lend;
}
if (c < 248) {
   char_length = 4;
}
goto Lend;
  }
}


Andrei

On 10/10/16 9:39 PM, Stefan Koch wrote:

This version has 24 instructions but these have a smaller encoding then
and are generally inexpensive
With inline asm and conditional moves it would be possible to reduce
this even further
to ~20 instructions.

void popFront1(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  size_t char_length = 1;
  if (c < 127)
  {
goto Lend;
  } else {
if ((c & 0b1100_) == 0b1000_)
{
  // This is invalid as a first char
  goto Lerror;
}
if (c < 192)
{
  char_length = 2;
  goto Lend;
}
if (c < 240) {
  char_length = 3;
  goto Lend;
}
if (c < 248) {
   char_length = 4;
  goto Lend;
}

//These characters are also no longer valid
Lerror : assert(0);
  }
  Lend :
  s = s.ptr[char_length .. s.length];
}

Re: color lib

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 11 October 2016 at 00:10:04 UTC, Nicholas Wilson 
wrote:
What about forwarding the array ops to a foreach of the static 
array?

Like as above but instead of:

ElementType!(R)[N] batch;

have:

static struct Batch
{
ElementType!(R)[N] elements;
auto get() { return elements[];}

Batch opBinary(string op)(Batch rhs) 
if(hasOperator!(ElementType!(R),op))

{
Batch b;
foreach(i; iota(N)) mixin("b.elements[i] = elememts[i]" 
~op~"rhs.elements[i]");

return b;
}
//repeat for opUnary,opOpAssign...
}
Batch batch;

I'll make another forum thread for this.


whoops missed an
alias get this;

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

This version has 24 instructions but these have a smaller 
encoding then and are generally inexpensive
With inline asm and conditional moves it would be possible to 
reduce this even further

to ~20 instructions.

void popFront1(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  size_t char_length = 1;
  if (c < 127)
  {
goto Lend;
  } else {
if ((c & 0b1100_) == 0b1000_)
{
  // This is invalid as a first char
  goto Lerror;
}
if (c < 192)
{
  char_length = 2;
  goto Lend;
}
if (c < 240) {
  char_length = 3;
  goto Lend;
}
if (c < 248) {
   char_length = 4;
  goto Lend;
}

//These characters are also no longer valid
Lerror : assert(0);
  }
  Lend :
  s = s.ptr[char_length .. s.length];
}

Re: Code signing to help with Windows virus false positives

[Martin Nowak via Digitalmars-d]

On Saturday, 20 August 2016 at 13:45:11 UTC, Basile B. wrote:

"to MSI using innosetup" ?

There's a misunderstanding here. Inno setup doesn't compile to 
MS installer, it's a complete independant solution.


Whatever makes more sense. From my very limited understanding 
.msi installers are natively understood installers in Windows, 
and the weapon of choice for robust and more professional 
installers.
If innosetup is just another NSIS like tool, it might not solve 
all our problems.


We're fairly clueless here and could really use help here.

Just signing the NSIS installers could work for now, any support 
for this hypothesis.
I tried to submit the latest release as sample to Microsoft but 
their file upload had a size limit smaller than the binary.

Re: MemberDefaults trait

[Ali Çehreli via Digitalmars-d-learn]

On 10/10/2016 04:50 PM, Ali Çehreli wrote:

> static if (!is(T == struct)) {
> static assert(T.stringof ~ " is not a struct type");
> }

Wow! That's a nice brain fart on my part. Ok, I can fix that one... :)

Ali

Re: Current State of the GC?

[rikki cattermole via Digitalmars-d-learn]

On 11/10/2016 10:12 AM, Martin Lundgren wrote:

I've been reading up a bit on the D garbage collector. Seen mostly
negative things about it. I've also seen a lot of proposals and what
not, but not much about the current state of things.

The latest page I can find about it is 2015H1. It mentions improving the
GC and making libraries less reliant on it. However, I can't find *any*
information about what GC improvements have been made. No up to date
performance comparisons, etc.

So what's been happening in memory management land lately? Bad GC seems
like one of the Dlangs weak points, so showing improvements here could
definitely bring more people in.


Well I can't say what has happened since that half way document.
Most of the work that goes on is minor tweaks and improvements that 
pretty much nobody outside of druntime knows about and that is quite all 
right.


If you want to actually see all these things going on check out Github[0].

Anyway, most of the time the GC isn't a problem, contrary to popular 
belief. As long as you do tricks like reusing memory it will never fire 
and more importantly you won't be hit with memory allocation costs. So 
basically a double win for you in terms of speed.


When dealing with multi threading you probably want to disable the GC 
collection and have predefined points so it can collect safely with no 
performance hits.


In reality, except for some cycle counting points, you won't need a 
million dollar GC and even then they tend to fail at those sort of jobs.


[0] 
https://github.com/dlang/druntime/tree/2db828bd4f21807254b770b3ec304f14596a9805/src/gc

Re: color lib

[Nicholas Wilson via Digitalmars-d]

On Sunday, 9 October 2016 at 13:28:05 UTC, Manu wrote:
On 9 October 2016 at 15:34, Ilya Yaroshenko via Digitalmars-d 
 wrote:

On Sunday, 9 October 2016 at 05:21:32 UTC, Manu wrote:


On 9 October 2016 at 14:03, Nicholas Wilson via Digitalmars-d 
 wrote:


[...]



Well the trouble is the lambda that you might give to 'map' 
won't work anymore. Operators don't work on batches, you need 
to use a completely different API, and I think that's 
unfortunate.



Could you please give an example what type of operation should 
be vectorized?


Even operations that don't require shuffling, eg:
  RGBA8[] a, b;
  zip(a, b).map!(e => e[0] + e[1]).copy(output);

Which I've suggested before (and Walter liked the idea), could 
be
sugared up by making use of the languages largely under-used 
array

operation syntax:
  output[] = a[] + b[]; // ie, types have overloaded addition
operators, so this array expression would be lowered to the 
pipeline
expression above. This would be super-useful for HEAPS of 
things!


Even these still need to be done in batches since colour adds 
are saturating operations, and there are SIMD instructions for 
saturating arithmetic, so we basically always have to do colour 
work in SIMD, which means batching, and that basically ruins 
any chance for natural, readable, expressions in your code. I 
want to find a way that we can express these operations 
naturally, without having to always manually handle the 
batching.


If we can get there, then I will say D is a good language for 
stream-data processing.


What about forwarding the array ops to a foreach of the static 
array?

Like as above but instead of:

ElementType!(R)[N] batch;

have:

static struct Batch
{
ElementType!(R)[N] elements;
auto get() { return elements[];}

Batch opBinary(string op)(Batch rhs) 
if(hasOperator!(ElementType!(R),op))

{
Batch b;
foreach(i; iota(N)) mixin("b.elements[i] = elememts[i]" 
~op~"rhs.elements[i]");

return b;
}
//repeat for opUnary,opOpAssign...
}
Batch batch;

I'll make another forum thread for this.

MemberDefaults trait

[Ali Çehreli via Digitalmars-d-learn]

Could you please review the following template to see whether it makes 
sense. It produces an AliasSeq type consisting of the default values of 
the members of a struct. It should and does support members that are 
initialized with '= void'. I could not achieve this with std.traits or 
__traits.


However, I'm not that happy with the use of __traits(compiles) below. 
Can this be improved?


Thank you,
Ali


import std.meta;

/** Get as an expression tuple the default values of members of a struct. */
template MemberDefaults(T) {
static if (!is(T == struct)) {
static assert(T.stringof ~ " is not a struct type");
}

import std.traits : FieldNameTuple;
enum t = T.init;
alias fields = FieldNameTuple!T;

template get(size_t i) {
static if (__traits(compiles, { enum _ = t.tupleof[i]; })) {
enum get = t.tupleof[i];
}
else {
alias get = void;
}
}

template Impl(size_t i = 0) {
import std.meta : AliasSeq;
static if (i == fields.length) {
alias Impl = AliasSeq!();
} else {
alias Impl = AliasSeq!(get!i, Impl!(i+1));
}
}

alias MemberDefaults = Impl!();
}

unittest {
struct S {
int i = 42;
string s = "hello";
char c = 'c';
}

static assert(MemberDefaults!S == AliasSeq!(42, "hello", 'c'));
}

unittest {
struct S {
int i = 42;
int j = void;
}

static assert(MemberDefaults!S[0] == 42);
static assert(is(MemberDefaults!S[1] == void));
}

void main() {
}

Re: color lib

[Manu via Digitalmars-d]

On 10 October 2016 at 23:41, Andrea Fontana via Digitalmars-d
 wrote:
> On Monday, 10 October 2016 at 13:25:07 UTC, Manu wrote:
>>
>> On 10 October 2016 at 23:00, Andrea Fontana via Digitalmars-d
>>  wrote:
>>>
>>> On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
>>>
>>> From doc:
>>> colorFromString Create a color from a string. May be a hex color in the
>>> standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the name of any
>>> color from the Colors enum.
>>>
>>> It seems it reads just rgb. (+ enum)
>>>
>>> I think that:
>>> colorFromString("red");
>>> colorFromString!"rgb"("#3212ff");
>>> colorFromString!"bgra"("#ff1232dd");
>>>
>>> makes more sense.
>>>
>>> Andrea
>>
>>
>> Why? I see no value in that function being a template... It's not like you
>> can confuse "#FF0080" and "LightGoldenrodYellow". As far as I know, there's
>> no possible ambiguity in colour strings, so why make them separate
>> functions?
>
>
> But it would be useful to create rgb, bgr, argb, bgra, or other color space
> using a string.

Give the preferred format as template arg?

> If a third party library or source gives me code in rgba, I have to
> preprocess it to convert as argb and then pass it to your library.

Sorry, what are we talking about? My lib supports basically every
format or arrangement I've ever encountered... you can work with
practically any data format you can think of.

> Anyway, I don't know if a code with letters a-f can be composed. In that
> case an ambiguity exists.

It must also be exactly 3,4,6,8 letters long, and begin with the
letter '#' or '$' ;)


I'm not sure why it matters what format the colour you have is...
Strings are in the form #RRGGBB, or #AARRGGBB. That is all.
It's the standard I've seen used everywhere ever, including the web,
which is a pretty good precedent :P
If you support swizzled forms of strings, then ambiguity exists.
Better not to allow it.

If you want a BGR from a string, use: colorFromString!BGR8("#FF");
If you want Lab: colorFromString!(Lab!float)("#FF");

Re: Stylish and dlang,org

[Nordlöw via Digitalmars-d]

On Saturday, 8 October 2016 at 08:58:37 UTC, Jakob Ovrum wrote:
On Saturday, 8 October 2016 at 08:03:50 UTC, Russel Winder 
wrote:
jmiller did a dark dlang.or Stylish style in 2012. It is now 
moderately (!) out of date. Anyone know if jmiller is around 
to update it, or if that is not possible someone who knows 
Stylish styles to create a new one so that we can view the 
site in lovely dark mode instead of the awful dark on light.


https://gist.github.com/JakobOvrum/e00f97f30bba4b24b6bc


How do I enable it? What Chrome extensions are preferred?

Re: New encryption block...

[sarn via Digitalmars-d]

On Monday, 10 October 2016 at 09:54:32 UTC, Era Scarecrow wrote:
 The largest portion would be that much like a hash, one small 
change will change the entire thing rather than a smaller 
portion (with the original blocksize). The multiple 
re-arranging and encryption steps is to ensure small changes 
affects every other block it was part of.


With CBC block mode, for example, all blocks later in the data 
stream are changed if one block is changed.  Earlier blocks 
aren't changed because CBC processes data in a single pass (which 
is an important practical requirement for a lot of applications). 
 If you wanted all the blocks to change, two passes would be 
enough.


 Just thinking that if someone makes a database of say the 
first 4 bytes expected in a file format (like gzip, bzip2, 
others, etc) then they can map most of the keys and immediately 
know how to decrypt it (assuming it's of a particular 
file/stream type).


Yep, this is one of the many reasons all secure block modes must 
use an IV (or equivalent).


BTW, if anyone's interested, here's a explanation of a real 
attack on short block size ciphers that doesn't assume background 
knowledge:

https://blog.cryptographyengineering.com/2016/08/24/attack-of-week-64-bit-ciphers-in-tls/
(The defence is to stop using crypto that was looking bad in the 
90s.)

Re: Linker Error: undefined reference to `internal'

[jython234 via Digitalmars-d]

I've tracked it down to two lines (which are the same):

private SyncLock lock = new SyncLock();

SyncLock is just an empty class which I use to construct objects 
for use in "synchronized" blocks (not sure if this is the right 
way to do this). Apparently if I move the initialization to the 
constructor there are no linker errors.

Re: Beta 2.072.0-b2

[Martin Nowak via Digitalmars-d-announce]

On Monday, 10 October 2016 at 10:45:37 UTC, Sönke Ludwig wrote:
Would have been nice in theory to have real void initialization 
of course, plus it was there for working around that (fixed?) 
issue with slow compilation times for large static arrays, but 
there is probably no real reason now to keep it.


Here is the ER for using `= void` field initializers.
[Issue 11331 – Inefficient initialization of struct with members 
= void](https://issues.dlang.org/show_bug.cgi?id=11331)

[Issue 11331] Inefficient initialization of struct with members = void

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11331

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #6 from Martin Nowak  ---
It's almost somewhat of a language fix, b/c they are silently ignored,
everybody expects them to work (seen that discussion/mistake several times
already, recent occurence
https://forum.dlang.org/post/ntfrgh$1l2n$1...@digitalmars.com).

Until we use that information for more efficient initialization we should
probably warn about that = void on a struct field has no effect.

--

Re: How to correctly display accented characters at the Windows prompt?

[Martin Krejcirik via Digitalmars-d-learn]

Windows. You can try command cp 65001 in the console window


chcp 65001

scone 1.2.0

[vladdeSV via Digitalmars-d-announce]

scone, Simple CONsole Engine, version 1.2.0 has just been 
released!

https://github.com/vladdeSV/scone/releases/tag/v1.2.0

This version includes a restructure of the whole project (should 
not affect applications), and the addition of a progress bar to 
the current UI library + bug fix.


Feedback is always appreciated!

Re: Linker Error: undefined reference to `internal'

[Walter Bright via Digitalmars-d]

On 10/10/2016 12:23 PM, jython234 wrote:

ld fails with this message:

Linking...
../git/mango-engine/bin/libmango-engine.a(gl_model_503_284.o):(.data._D12mango_engine8graphics6opengl8gl_model7GLModel6__initZ+0x10):
undefined reference to `internal'
../git/mango-engine/bin/libmango-engine.a(shader_51b_52f.o):
(.data._D12mango_engine8graphics6shader13ShaderProgram6__initZ+0x18):
undefined reference to `internal'

I have no idea what this means, and have never seen it before.


A symbol remains undefined after all input files, including libraries, had been 
processed. Common causes for this are:


A function was called in your code, but the function was never written.

A virtual function was declared, but never written.

A data variable was referenced, but never defined anywhere.

Did not specify all the .obj files to the linker.

The calling conventions of the function being referenced do not match the 
calling conventions of the defined function. Compiler switches, memory models, 
and special keywords can all affect calling convention (and thereby the name of 
the symbol as it appears in the .obj file).


One or more missing library files (.lib). One way to figure out which .lib file 
contains the missing symbol is to run:


\dm\bin\grep symbolname \dm\lib\*.*

The LIB environment variable is missing or not pointing to the \dm\lib directory 
or wherever the .lib files reside.

Re: How to correctly display accented characters at the Windows prompt?

[Martin Krejcirik via Digitalmars-d-learn]

On Monday, 10 October 2016 at 19:31:14 UTC, Cleverson Casarin 
Uliana wrote:
Hi Martin, indeed, here in my workplace Windows machine there 
is no "CP_UTF_8" codepage, nor there is 65001. I was waiting to


codepage 65001 (UTF8) should be available on all modern Windows. 
You can try command cp 65001 in the console window (and change 
your font accordingly).


Just for info, this is probably a d related bug, because the 
Racket language for example has a (reencode-output-port) 
function, and it Works.


I don't know know about Racket, but D's problems are related to 
the C runtime library. Here is what I found out:


-m32 (uses DM C library): output to stdout works, but stderr is 
broken (corrupt accented characters, or total output freeze).

https://issues.dlang.org/show_bug.cgi?id=1448

-m32mscoff and -m64 (Microsoft C runtime): broken characters and 
some mysterious failures.

https://issues.dlang.org/show_bug.cgi?id=15761

So this leaves transcoding as the only viable solution. Luckily, 
there is std.windows.charset.toMBSz function you can use.

[Issue 16606] New: [dlang.org] Search field value not propagated to Google

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16606

  Issue ID: 16606
   Summary: [dlang.org] Search field value not propagated to
Google
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/library/std/math.html
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: lluce...@gmail.com

Searching in the search field of dlang.org leads to Google having only
"site:dlang.org/library" as the search term. The searched term written in the
dlang.org's search field is not propagated to Google.

--

Re: How to correctly display accented characters at the Windows prompt?

[Cleverson Casarin Uliana via Digitalmars-d-learn]

Hi Martin, indeed, here in my workplace Windows machine there is no
"CP_UTF_8" codepage, nor there is 65001. I was waiting to try it later
on my home machine, but since you say it's broken, then I'll need to
look for a way to convert the actual string to the 850 codepage...

Just for info, this is probably a d related bug, because the Racket
language for example has a (reencode-output-port) function, and it
Works.

Greetings,
Cleverson

Linker Error: undefined reference to `internal'

[jython234 via Digitalmars-d]

I posted this on stackoverflow, but it doesn't seem like anyone 
knows what is going on:


I'm writing an application in D which interfaces with OpenGL and 
a few other native libraries (using the Derelict libraries). 
However, this error does not seem to relate to that at all.


Whenever I do "dub build" the compilation succeeds, but ld fails 
with this message:


Linking...
../git/mango-engine/bin/libmango-engine.a(gl_model_503_284.o):(.data._D12mango_engine8graphics6opengl8gl_model7GLModel6__initZ+0x10):
 undefined reference to `internal'
../git/mango-engine/bin/libmango-engine.a(shader_51b_52f.o):
(.data._D12mango_engine8graphics6shader13ShaderProgram6__initZ+0x18): undefined reference to `internal'

collect2: error: ld returned 1 exit status

I have no idea what this means, and have never seen it before. 
Also, strangely this error only occurs when I import the specific 
files: gl_model.d and shader.d, from another DUB project. If they 
are not imported the linker succeeds.


I'm not sure what information to provide, so I will just link the 
whole source code: https://github.com/jython234/mango-engine

Re: opIndexDispatch?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, October 10, 2016 19:01:19 Yuxuan Shui via Digitalmars-d-learn 
wrote:
> Hi,
>
> Why is there no opIndexDispatch for overloading a[x].func() ?

There's opIndex for overloading a[x], and then you can call a function on
the return value. If you want some kind of opDispatch on the return value,
then the return type will need to implement opDispatch.

- Jonathan M Davis

opIndexDispatch?

[Yuxuan Shui via Digitalmars-d-learn]

Hi,

Why is there no opIndexDispatch for overloading a[x].func() ?

[Issue 16602] Implicit string concatenation and precedence of ~

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16602

Andrej Mitrovic  changed:

   What|Removed |Added

  Component|dmd |dlang.org

--

Re: Required DMD changes for Mir and few thoughts about D future

[Matthias Klumpp via Digitalmars-d]

On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu 
wrote:

On 10/8/16 2:49 PM, Andrei Alexandrescu wrote:

On 10/8/16 1:22 PM, Martin Nowak wrote:
Integrating this with a pre-compiled ldc library is a 
fantastic idea

OTOH.
If we can make this work, it will be much less effort and 
yield the
fastest implementation. Also would speed up the development 
cycle a bit

b/c the kernels don't need to be recompiled/optimized.


You mean dmd/ldc/etc interop at binary level? Yes, that would 
be pretty

rad indeed! -- Andrei


(after thinking a bit more) ... but Mir seems to rely in good 
part on templates, which makes pre-compiled libraries less 
effective. -- Andrei


Independent from Mir, a stable ABI for D which all compilers 
follow would be a tremendous win, especially from the perspective 
of shipping D stuff in Linux distributions.

So maybe this is worth attempting?

[Issue 16560] [Mir] Prefetch intrinsics like in LDC

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16560

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/09e3fdd31d53fcb96a787a6a9de466a7c1f72ac1
fix Issue 16560 - [Mir] Prefetch intrinsics like in LDC

https://github.com/dlang/dmd/commit/0fc8be57bb0107a718ac2dabd1b5482c1ebe89ef
Merge pull request #6188 from WalterBright/fix16560

fix Issue 16560 - [Mir] Prefetch intrinsics like in LDC

--

Re: ptrdiff_t of class.tupleof entry

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, October 10, 2016 17:57:15 Satoshi via Digitalmars-d-learn wrote:
> Hello,
> How can I take an ptrdiff_t of any tupleoff entry from class
> during compilation?
>
>
> I need something like this:
>
> template Test(T, int i) {
>   enum Test = [i] - [0];
> }
>
>
> and then use it like:
>
> class AnyClass {
> int a;
> int b;
> int c;
> string d;
>
> }
>
> enum Addr = Test!(AnyClass, 3);
>
> void assignInt!(T)(AnyClass cls, T value) {
> *(cast(T *)cast(void *)cls + Addr) = value;
> }
>
>
>
> This is just an example how I need to use it.
> Is something like this possible to do?

You can use the offsetof property of a member variable to find out the
offset between its address and the address of the beginning of the class or
struct that it's a member of.

- Jonathan M Davis

ptrdiff_t of class.tupleof entry

[Satoshi via Digitalmars-d-learn]

Hello,
How can I take an ptrdiff_t of any tupleoff entry from class 
during compilation?



I need something like this:

template Test(T, int i) {
 enum Test = [i] - [0];
}


and then use it like:

class AnyClass {
int a;
int b;
int c;
string d;

}

enum Addr = Test!(AnyClass, 3);

void assignInt!(T)(AnyClass cls, T value) {
*(cast(T *)cast(void *)cls + Addr) = value;
}



This is just an example how I need to use it.
Is something like this possible to do?

Re: How to correctly display accented characters at the Windows prompt?

[Martin Krejcirik via Digitalmars-d-learn]

Thanks,
Cleverson


Call SetConsoleOutputCP(CP_UTF8).


No, this may appear to to work, but in reality, it's broken. The 
only reliable way is to convert to the native windows codepage.

[Issue 259] Comparing signed to unsigned does not generate an error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=259

--- Comment #66 from thomas.bock...@gmail.com ---
Oops! That's the wrong DMD bug. This is the one I
actually meant:
https://issues.dlang.org/show_bug.cgi?id=14835

--

[Issue 259] Comparing signed to unsigned does not generate an error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=259

thomas.bock...@gmail.com changed:

   What|Removed |Added

 CC||thomas.bock...@gmail.com

--- Comment #65 from thomas.bock...@gmail.com ---
(In reply to Andrei Alexandrescu from comment #64)
> We should be fine with a slight loss in efficiency in
> mixed sign compare.

The previously agreed upon solution was to default to
warning about each signed/unsigned comparison, but omit
the warning if VRP could prove it to be safe. There is
no loss of run-time efficiency that way, but some code
will break and require an explicit cast to fix.

Are you suggesting that we should just insert an extra
comparison to zero as needed, instead?

I'd support that, but I don't know how others
(including Walter Bright) would feel about it. The
real performance impact should be immeasurably small
in nearly all cases (especially with the VRP upgrades
discussed below).

> What active PRs are open at this time?

My DMD #5229 is a continuation of Lionello's work
toward improving VRP sufficiently to minimize code
breakage:
https://github.com/dlang/dmd/pull/5229

However, it's stuck pending a resolution to another
DMD bug:
https://issues.dlang.org/show_bug.cgi?id=15585

If #5229 ever gets pulled, one more tricky VRP-
related follow-up is required to make the compiler
smart enough. After that, actually fixing this bug
is trivial: I've had that patch ready to go for about
a year now, but can't submit it until the VRP stuff
is straightened out because it causes too much
breakage.

--

Re: isRvalue trait

[Nordlöw via Digitalmars-d-learn]

On Monday, 10 October 2016 at 12:22:54 UTC, Marc Schütz wrote:

I would like to overload to an identity op.


If the compiler is smart enough to understand what 
`moveEmplace()` does, it could already do this automatically.


Doh! My mistake.

I'll use `moveEmplace`, then.

Thx!

Re: Easy sockets - don't exist yet?

[Konstantin Kutsevalov via Digitalmars-d-learn]

On Monday, 10 October 2016 at 07:37:48 UTC, Bauss wrote:
Wrote some pretty simple sockets that you could use (Based on 
vibe.d though.)


https://github.com/bausshf/cheetah


Hi,

Yes I saw it, but not sure. Does it make sense to use vibe.d only 
for sockets. I mean, it like a web framework with many 
dependencies etc...

Re: Easy sockets - don't exist yet?

[Konstantin Kutsevalov via Digitalmars-d-learn]

On Monday, 10 October 2016 at 02:54:09 UTC, Jonathan M Davis 
wrote:
On Monday, October 10, 2016 01:43:54 Konstantin Kutsevalov via 
So, it's simply gone. But if someone wants to propose a 
replacement, they're certainly still free to do so.


- Jonathan M Davis


I see, thank you for answer

Re: Why can't static arrays be sorted?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, October 10, 2016 16:29:41 TheGag96 via Digitalmars-d-learn wrote:
> On Saturday, 8 October 2016 at 21:14:43 UTC, Jon Degenhardt wrote:
> > This distinction is a bit on the nuanced side. Is it behaving
> > as it should?
> >
> > --Jon
>
> I think so? It's not being modified in the second case because
> the array is being passed by value... "x" there is a reference to
> an element of the copy created to be passed to each(). I assume
> there's a good reason why ranges in general are passed by value
> into these functions -- except in this one case, the stuff inside
> range types copied when passed by value won't be whole arrays,
> I'm guessing.

Whether it's by value depends entirely on the type of the range. They're
passed around, and copying them has whatever semantics it has. In most
cases, it copies the state of the range but doesn't copy all of the elements
(e.g. that's what happens with a dynamic array, since it gets sliced). But
if a range is a class, then it's definitely a reference type.  The only way
to properly save the state of a range is to call save.

But passing by ref would make no sense at all with input ranges. It would
completely kill chaining them. Almost all range-based functions return
rvalues.

- Jonathan M Davis

Re: Why can't static arrays be sorted?

[TheGag96 via Digitalmars-d-learn]

On Saturday, 8 October 2016 at 21:14:43 UTC, Jon Degenhardt wrote:
This distinction is a bit on the nuanced side. Is it behaving 
as it should?


--Jon


I think so? It's not being modified in the second case because 
the array is being passed by value... "x" there is a reference to 
an element of the copy created to be passed to each(). I assume 
there's a good reason why ranges in general are passed by value 
into these functions -- except in this one case, the stuff inside 
range types copied when passed by value won't be whole arrays, 
I'm guessing.

Re: How to correctly display accented characters at the Windows prompt?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, October 10, 2016 13:24:09 Cleverson Casarin Uliana via Digitalmars-
d-learn wrote:
> Hello John and all, how do you search for a given function to see
> where it is defined/declared? I tried to find SetConsoleOutputCP by
> myself, but the search embeded in the documentation cannot find
> anything in the phobos library refference, and searching the entire
> site returns forum posts only.

It looks like it's in

core.sys.windows.wincon;

- Jonathan M Davis

Re: How to correctly display accented characters at the Windows prompt?

[Cleverson Casarin Uliana via Digitalmars-d-learn]

Hello John and all, how do you search for a given function to see
where it is defined/declared? I tried to find SetConsoleOutputCP by
myself, but the search embeded in the documentation cannot find
anything in the phobos library refference, and searching the entire
site returns forum posts only.

Thanks,
Cleverson

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Monday, 10 October 2016 at 15:17:05 UTC, Stefan Koch wrote:
On Monday, 10 October 2016 at 03:55:17 UTC, Andrei Alexandrescu 
wrote:


Oh, forgot to mention: the initial/short path should only 
check for ASCII, i.e. c < 0x80. -- Andrei


Since in this case stability of min is concern, you can shave of 
another 2 instructions by writing the comparison by hand


void popFront1(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  size_t char_length = 1;
  if (!(c & 0x80)) {
goto Lend;
  } else {
import core.bitop;
uint i = 7u - bsr(~c | 1u);
import std.algorithm;
if (i > 6u) goto Lend;
char_length = i < s.length ? i : s.length;
  }
  Lend :
  s = s.ptr[char_length .. s.length];
}

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Monday, 10 October 2016 at 15:37:09 UTC, Stefan Koch wrote:
Since in this case stability of min is concern, you can shave 
of another 2 instructions by writing the comparison by hand


In this case the stability of min is +NO+ concern.

Re: Project Highlight: DlangUI

[Vadim Lopatin via Digitalmars-d-announce]

On Monday, 10 October 2016 at 14:32:43 UTC, Mike Parker wrote:

On Monday, 10 October 2016 at 13:26:59 UTC, Vadim Lopatin wrote:

Mike, is it possible to add screenshot to article before 
Console UI screenshot?
People getting confused by text UI screenshot, thinking it's 
normal for DlangUI.


Good candidate: 
http://buggins.github.io/dlangui/screenshots/screenshot-example1-windows.png


Good idea. I've updated the post.


Thank you!

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Monday, 10 October 2016 at 03:55:17 UTC, Andrei Alexandrescu 
wrote:


Oh, forgot to mention: the initial/short path should only check 
for ASCII, i.e. c < 0x80. -- Andrei


void popFront1(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  size_t char_length = 1;
  if (!(c & 0x80)) {
goto Lend;
  } else {
import core.bitop;
uint i = 7u - bsr(~c | 1u);
import std.algorithm;
if (i > 6u) goto Lend;
char_length = min(i, s.length);
  }
  Lend :
  s = s.ptr[char_length .. s.length];
}


This one removes one unnecessary ret.
It will also probably be better for the branch-predictor.

Re: Supporting musl libc

[Daniel Kozak via Digitalmars-d]

Dne 10.10.2016 v 15:27 openwrt via Digitalmars-d napsal(a):


On Sunday, 9 October 2016 at 15:48:49 UTC, Daniel Kozak wrote:

On Sunday, 9 October 2016 at 13:38:33 UTC, Jacob Carlborg wrote:

On 2016-10-08 20:47, Daniel Kozak wrote:


What is the current status? Without support of musl-libc, I can not ad
support for a Alpine linux distribution. It is a shame because they
already have go and rust support.


I've not worked at this at all. For my use case it was easier to 
just build in Docker instead.


I solved this by using libexecinfo library from freebsd


openwrt also use musl,  and I can not run my d code on it(unless I 
rebuild everythings with glic).
Yes, even libexecinfo does not fixed all issues, we really need to add 
other C runtimes. In D runtime and phobos there is a lot of places 
which  wrongly use version(linux) instead of CRuntime_Glibc.

Re: How to correctly display accented characters at the Windows prompt?

[John C via Digitalmars-d-learn]

On Monday, 10 October 2016 at 14:14:08 UTC, Cleverson Casarin 
Uliana wrote:
Hello, when I run a compiled Windows executable at the console, 
letters outside the ascii range such as ç and ã do not display 
propperly. Is there any d function to change the console code 
page on the fly? My Windows console code page, which is for 
Brazilian Portuguese, is at 850. Perhaps an alternative would 
be to convert d strings from Unicode to the 850 code page on 
the fly.


Thanks,
Cleverson


Call SetConsoleOutputCP(CP_UTF8).

[Issue 16558] [Mir] Generic unaligned load/store like (like LDC loadUnaligned and storeUnaligned)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16558

--- Comment #8 from Илья Ярошенко  ---
I completely forgot that loadUnaligned is inlineIR alias.
So, LDC can just use an alias for loadUnaligned. So, it can to be generic
function, which will an alias for LDC Druntime.

Walter, sorry for the noise!


template loadUnaligned(V)
if(is(typeof(llvmVecType!V)))
{
...
alias inlineIR!(ir, V, const(T)*) loadUnaligned;
}

--

Re: Project Highlight: DlangUI

[Mike Parker via Digitalmars-d-announce]

On Monday, 10 October 2016 at 13:26:59 UTC, Vadim Lopatin wrote:

Mike, is it possible to add screenshot to article before 
Console UI screenshot?
People getting confused by text UI screenshot, thinking it's 
normal for DlangUI.


Good candidate: 
http://buggins.github.io/dlangui/screenshots/screenshot-example1-windows.png


Good idea. I've updated the post.

How to correctly display accented characters at the Windows prompt?

[Cleverson Casarin Uliana via Digitalmars-d-learn]

Hello, when I run a compiled Windows executable at the console,
letters outside the ascii range such as ç and ã do not display
propperly. Is there any d function to change the console code page on
the fly? My Windows console code page, which is for Brazilian
Portuguese, is at 850. Perhaps an alternative would be to convert d
strings from Unicode to the 850 code page on the fly.

Thanks,
Cleverson

[Issue 16593] Building "tools" produces deprecation warnings

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16593

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/tools

https://github.com/dlang/tools/commit/6a257202a1593cf8f5dabc8704cd49112190962b
Fix Issue 16593 - Building "tools" produces deprecation warnings

https://github.com/dlang/tools/commit/3a32331303e2e62f429b8136ba0de0e9a9294722
Merge pull request #201 from CyberShadow/pull-20161004-212702

Fix Issue 16593 - Building "tools" produces deprecation warnings

--

[Issue 16593] Building "tools" produces deprecation warnings

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16593

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: color lib

[Andrea Fontana via Digitalmars-d]

On Monday, 10 October 2016 at 13:25:07 UTC, Manu wrote:
On 10 October 2016 at 23:00, Andrea Fontana via Digitalmars-d 
 wrote:

On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:

From doc:
colorFromString Create a color from a string. May be a hex 
color in the
standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the 
name of any

color from the Colors enum.

It seems it reads just rgb. (+ enum)

I think that:
colorFromString("red");
colorFromString!"rgb"("#3212ff");
colorFromString!"bgra"("#ff1232dd");

makes more sense.

Andrea


Why? I see no value in that function being a template... It's 
not like you can confuse "#FF0080" and "LightGoldenrodYellow". 
As far as I know, there's no possible ambiguity in colour 
strings, so why make them separate functions?


But it would be useful to create rgb, bgr, argb, bgra, or other 
color space using a string.


If a third party library or source gives me code in rgba, I have 
to preprocess it to convert as argb and then pass it to your 
library.


Anyway, I don't know if a code with letters a-f can be composed. 
In that case an ambiguity exists.

Re: Project Highlight: DlangUI

[Vadim Lopatin via Digitalmars-d-announce]

On Friday, 7 October 2016 at 13:45:36 UTC, Mike Parker wrote:
The latest post on the D Blog is all about Vadim's DlangUI. He 
shares some of the inspiration behind it, a few implementation 
details, and plans for the future.


The post: 
https://dlang.org/blog/2016/10/07/project-highlight-dlangui/
Reddit: 
https://www.reddit.com/r/programming/comments/56besf/dlangui_a_crossplatform_gui_written_in_and_for/


Screenshots on http://buggins.github.io/dlangui/screenshots.html 
are updated to taken from latest DlangUI.

Now they are clickable - click to see non-resized version.

Re: Project Highlight: DlangUI

[Vadim Lopatin via Digitalmars-d-announce]

On Friday, 7 October 2016 at 13:45:36 UTC, Mike Parker wrote:
The latest post on the D Blog is all about Vadim's DlangUI. He 
shares some of the inspiration behind it, a few implementation 
details, and plans for the future.


The post: 
https://dlang.org/blog/2016/10/07/project-highlight-dlangui/
Reddit: 
https://www.reddit.com/r/programming/comments/56besf/dlangui_a_crossplatform_gui_written_in_and_for/


Mike, is it possible to add screenshot to article before Console 
UI screenshot?
People getting confused by text UI screenshot, thinking it's 
normal for DlangUI.


Good candidate: 
http://buggins.github.io/dlangui/screenshots/screenshot-example1-windows.png

Re: Supporting musl libc

[openwrt via Digitalmars-d]

On Sunday, 9 October 2016 at 15:48:49 UTC, Daniel Kozak wrote:

On Sunday, 9 October 2016 at 13:38:33 UTC, Jacob Carlborg wrote:

On 2016-10-08 20:47, Daniel Kozak wrote:

What is the current status? Without support of musl-libc, I 
can not ad
support for a Alpine linux distribution. It is a shame 
because they

already have go and rust support.


I've not worked at this at all. For my use case it was easier 
to just build in Docker instead.


I solved this by using libexecinfo library from freebsd


openwrt also use musl,  and I can not run my d code on it(unless 
I rebuild everythings with glic).

Re: color lib

[Manu via Digitalmars-d]

On 10 October 2016 at 23:00, Andrea Fontana via Digitalmars-d
 wrote:
> On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
>
> From doc:
> colorFromString Create a color from a string. May be a hex color in the
> standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the name of any
> color from the Colors enum.
>
> It seems it reads just rgb. (+ enum)
>
> I think that:
> colorFromString("red");
> colorFromString!"rgb"("#3212ff");
> colorFromString!"bgra"("#ff1232dd");
>
> makes more sense.
>
> Andrea

Why? I see no value in that function being a template... It's not like
you can confuse "#FF0080" and "LightGoldenrodYellow". As far as I
know, there's no possible ambiguity in colour strings, so why make
them separate functions?

Re: color lib

[Andrea Fontana via Digitalmars-d]

On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
On 10 October 2016 at 17:29, Andrea Fontana via Digitalmars-d 
 wrote:

On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote:


I've done another pass incorporating prior feedback, mostly 
focusing on documentation.



http://dtest.thecybershadow.net/artifact/website-b6e2e44dd40dd7c70eb45829c02060b99ae3937b-57272ccdf902fa3f0c050d522129f2be/web/library-prerelease/std/experimental/color.html

Can interested parties please give it another once-over and 
add

further comments?
How can I get this to a point where people would like to see 
it in phobos?


Repo: https://github.com/TurkeyMan/color
PR: https://github.com/dlang/phobos/pull/2845



Nice work!

colorFromString should be colorFromRGBString :)


Nar. It parses any form of colour-in-a-string.


From doc:
colorFromString	Create a color from a string. May be a hex color 
in the standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be 
the name of any color from the Colors enum.


It seems it reads just rgb. (+ enum)

I think that:
colorFromString("red");
colorFromString!"rgb"("#3212ff");
colorFromString!"bgra"("#ff1232dd");

makes more sense.

Andrea

[Issue 16423] ModuleInfo missing when linking to static lib with classes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16423

--- Comment #7 from Martin Nowak  ---
(In reply to Steven Schveighoffer from comment #5)
> This is penny-wise and pound-foolish. First we need to solve megabyte sized
> template symbol names. Then we need full shared library support. The few
> kilobytes that moduleinfo adds is nothing. Trim out unused classinfo? Then
> we need to remove Object.factory method.

- Yes we need to solve the long symbol names, but they don't bloat the code
segment or affect the performance
- shared libraries were just one workaround I named (and they can be fully used
on linux/FreeBSD atm.)
- It's not the ModuleInfo or the ClassInfo, it's the fact, that this drags in
the complete tree of symbols reachable by any referenced class, i.e. the whole
module in most cases. The static constructors and class references are one of
the main reasons for our huge binaries (code segment, not file size which is
just a distribution problem).
- Object.factory is slow by design, it's in the interest of everyone to avoid
that facility if possible, and there aren't many use-cases that really require
it

If we have enough prove that it's a necessary pattern, I'd be in favor of
adding a global, synchronized, namespaced dynamic class registration facility
in phobos or druntime. That could be used for certain patterns such as
registering deserializable subclasses, factory.register!("orange.deserializer",
MyOpenSubclass).
It could also make use of a hash table to speed up instantiating, and maybe
even support non-standard constructors.
The question is really, do we really need it, and who builds it.

--

Re: color lib

[Ethan Watson via Digitalmars-d]

On Monday, 10 October 2016 at 12:10:56 UTC, Jacob Carlborg wrote:

Isn't std.typecons.Flag metaprogramming ;)


Hahaha, oh wow. If ever there was a case for mixins.

Re: isRvalue trait

[Marc Schütz via Digitalmars-d-learn]

On Monday, 10 October 2016 at 11:46:01 UTC, Nordlöw wrote:

At

https://github.com/nordlow/phobos-next/blob/master/src/moval.d

I've implemented a helper function for creating r-value out of 
l-values defined as


E movedToRvalue(E)(ref E e)
{
import std.algorithm.mutation : move;
E value;
move(e, value); // this can be optimized
return value;
}



Doesn't the second overload of `move()` already do what you want?

https://dlang.org/phobos/std_algorithm_mutation.html#.move

Note that in your implementation, you needlessly initialize 
`value`, which then needs to be properly destroyed by `move()`, 
which the Phobos implementation avoids:


https://github.com/dlang/phobos/blob/master/std/algorithm/mutation.d#L1083-L1088

For the case when movedToRvalue is called with an r-value, such 
as in,


static assert(__traits(compiles, { consume(S(14)); }));

I would like to overload to an identity op.


If the compiler is smart enough to understand what 
`moveEmplace()` does, it could already do this automatically.

Re: color lib

[Jacob Carlborg via Digitalmars-d]

On 2016-10-10 12:39, Ethan Watson wrote:


I'm especially trying to make Binderoo readable as there's so many
programmers that are scared by metaprogramming.


Isn't std.typecons.Flag metaprogramming ;)

--
/Jacob Carlborg

Re: Beta 2.072.0-b2

[Dicebot via Digitalmars-d-announce]

On Sunday, 9 October 2016 at 22:01:31 UTC, Martin Nowak wrote:

On Sunday, 9 October 2016 at 14:36:49 UTC, Dicebot wrote:

Which branch changelog content is generated from?


Stable, the changelog is also included in the docs that are in 
the packages.

I do merge stable back into master to publish them though.


I am confused in that case. What shall I do to replace 
http://dlang.org/changelog/2.072.0.html#dash_safe with my changes 
from https://github.com/dlang/dmd/blob/stable/changelog.dd ?

Re: isRvalue trait

[Nordlöw via Digitalmars-d-learn]

On Monday, 10 October 2016 at 11:51:09 UTC, Nordlöw wrote:

Found it:

http://forum.dlang.org/post/n8m8bh$2vgc$1...@digitalmars.com
https://issues.dlang.org/show_bug.cgi?id=15634


Ok, so I added `isLvalue` and `isRvalue` to

https://github.com/nordlow/phobos-next/blob/master/src/moval.d

Now the next follow-up question becomes how to use it to 
restrict/overload my definition of `movedToRvalue()` since 
`isLvalue` takes an alias as argument and `movedToRvalue` takes a 
reference to an instance. How to solve this?

Re: isRvalue trait

[Nordlöw via Digitalmars-d-learn]

On Monday, 10 October 2016 at 11:46:01 UTC, Nordlöw wrote:

Is there one?


Found it:

http://forum.dlang.org/post/n8m8bh$2vgc$1...@digitalmars.com
https://issues.dlang.org/show_bug.cgi?id=15634

isRvalue trait

[Nordlöw via Digitalmars-d-learn]

At

https://github.com/nordlow/phobos-next/blob/master/src/moval.d

I've implemented a helper function for creating r-value out of 
l-values defined as


E movedToRvalue(E)(ref E e)
{
import std.algorithm.mutation : move;
E value;
move(e, value); // this can be optimized
return value;
}

For the case when movedToRvalue is called with an r-value, such 
as in,


static assert(__traits(compiles, { consume(S(14)); }));

I would like to overload to an identity op.

Is this currently possible somehow? I cannot find any trait 
`isRvalue` that fulfills


static assert(isRvalue!(S(14)));

Is there one?

Re: When to call GC.{add,remove}Range in containers?

[Nordlöw via Digitalmars-d-learn]

On Monday, 10 October 2016 at 08:26:45 UTC, Kagamin wrote:

On Monday, 10 October 2016 at 07:12:10 UTC, Nordlöw wrote:

should not be scanned by the GC.


Shouldn't be a problem.


What do you mean?

I'm talking about an optimization; don't call addRange when we 
don't need to, because the internal stored `E* _ptr` is 
maintained manually by calls to `*alloc` and `free`.

Re: Using gethostbyname_r instead of gethostbyname in std.socket

[MWumpusZ via Digitalmars-d]

On Saturday, 8 October 2016 at 13:46:28 UTC, Jakob Ovrum wrote:
...
The doc for InternetAddress does say it uses InternetHost 
internally, and the docs do recommend getAddress over using 
Internet{Host, Address} directly,


I have no idea why we don't use std.socket.getAddress; I'll look 
into that.  If switching over is viable (which I imagine it is) 
and sufficient, then that sounds like a great solution short term.


but maybe InternetHost.getHostByName should use getAddress 
internally to benefit from getaddrinfo.


Sounds good :)  I can't comment on what wider impact that might 
have though.


If not, it should probably at least warn about not being 
reentrant.


It is "kind of" reentrant - it has synchronisation around the 
gethostbyname call.  Things fall apart when gethostbyname is 
accessed directly, e.g. by a third party library, as is the case 
in our application.

Re: How do I load a shared library?

[Nafees via Digitalmars-d-learn]

Fixed this issue, stackoverflow helped 
http://stackoverflow.com/questions/39929495


just compiled the library with -fPIC -m32 -shared

Re: Beta 2.072.0-b2

[Sönke Ludwig via Digitalmars-d-announce]

Am 10.10.2016 um 12:20 schrieb Martin Nowak:

On Monday, 10 October 2016 at 09:03:53 UTC, Sönke Ludwig wrote:

Of course, the new error is more restrictive than it should be, namely
if the uninitialized pointer field gets written before the first read,
it would still be safe.


That's surprising b/c void initializers for struct fields didn't use to
work.


Hm, thanks for the hint - if that's still the case, that leads to the 
very simple workaround of simply removing the "= void". Would have been 
nice in theory to have real void initialization of course, plus it was 
there for working around that (fixed?) issue with slow compilation times 
for large static arrays, but there is probably no real reason now to 
keep it.



I need to research the intent behind this to say sth. detailed, though
usually an shouldn't break working code, only deprecate it.

Re: color lib

[Ethan Watson via Digitalmars-d]

On Saturday, 8 October 2016 at 13:06:42 UTC, Manu wrote:

Oh no, you too? >_<


Yeah, I've been going on a readability bender lately, especially 
in public facing code.


My thinking there is that statements in code that don't 
immediately give context are essentially a cipher. Because that's 
exactly what you need to do to understand the code - look 
something up to see what it means. Named parameters and variable 
names that provide the context avoid that to a large degree.


I'm especially trying to make Binderoo readable as there's so 
many programmers that are scared by metaprogramming. My GDCE talk 
spent a lot of time attempting to make it all understandable. 
Making the code descriptive seals the deal. If I can make my code 
more descriptive, and it compiles out just the same but makes the 
compiler do a bit more work... Make the compiler do more work and 
optimise the compiler.


I'm far more lax on not-publicly-facing code (so basically API 
implementations and supporting code that isn't part of a public 
interface). Anything I expect someone other than myself to 
interact with gets the readability treatment. Which, as you know, 
is important because readable code generally isn't efficient code 
- as is evidenced by the vectorisation/buffer processing thread 
going on in here.


It's also interesting how many programmers get vehemently 
defensive when you call out non-descriptive programming practices 
as programming for your own convenience and no one else. I have 
this argument with using i/j/k/foo/bar/etc in loops as well.


Incidentally, have you had a geez over the core API? An 
efficient API

will emerge when we work out how to work batched operations into
ranges...


Been slowly making my way through it. Seems solid enough, but I 
haven't looked through it all thoroughly yet.

Re: Beta 2.072.0-b2

[ag0aep6g via Digitalmars-d-announce]

On 10/10/2016 12:28 PM, Martin Nowak wrote:

It's on our heap and will be addressed soon.
Please look at our trello board.
https://trello.com/b/XoFjxiqG/active


These two 2.072 regressions seem to be missing from Trello:

https://issues.dlang.org/show_bug.cgi?id=16013
https://issues.dlang.org/show_bug.cgi?id=16273

[Issue 16574] [REG 2.072.0-b1] Unexplained errors about functions that overridde anything

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16574

--- Comment #7 from Martin Nowak  ---
Smells like due to the lazy alias, semantic analysis of the base class is
unfinished before checking the derived class' overload.

--

Re: Beta 2.072.0-b2

[Martin Nowak via Digitalmars-d-announce]

On Monday, 10 October 2016 at 10:06:25 UTC, Basile B. wrote:
Any news on the front of 
https://issues.dlang.org/show_bug.cgi?id=16574 ?


It's on our heap and will be addressed soon.
Please look at our trello board.
https://trello.com/b/XoFjxiqG/active

Re: Beta 2.072.0-b2

[Martin Nowak via Digitalmars-d-announce]

On Monday, 10 October 2016 at 09:03:53 UTC, Sönke Ludwig wrote:
Of course, the new error is more restrictive than it should be, 
namely if the uninitialized pointer field gets written before 
the first read, it would still be safe.


That's surprising b/c void initializers for struct fields didn't 
use to work.
I need to research the intent behind this to say sth. detailed, 
though usually an shouldn't break working code, only deprecate it.

Re: Add "Go To Source" for Docs?

[Jacob via Digitalmars-d]

On Sunday, 9 October 2016 at 06:50:00 UTC, Sönke Ludwig wrote:

Am 08.10.2016 um 23:49 schrieb Jacob:
Well a lot of the times I'm browsing the phobos library 
documentation I
want to go to the source code, but there's no easy way to go 
there
directly from the docs. Some modules have a link to the source 
file but
I think that's done manually as many of them don't. I think 
it'd be
beneficial to have a way to tell the doc generator to include 
a "go to
source" button at each doc entry of function/type. With the 
option to
set a github repo or other link as the destination of the 
link, it
should also include the line number when outputting the docs. 
Might be a
bit specific for github there though, as setting the line 
number just
involves adding a number to the end of the link. Whereas being 
able to
set a local file as a link might be desired as well. But I 
don't think
you can tell the OS to open the file at a certain line with 
just a file

uri.


The documentation under http://dlang.org/library/ has such a 
link at the top of each page. See for example 
http://dlang.org/library/std/algorithm/comparison/either.html


Is that generated using something else? Adding a similar feature 
to the other docs would do it then. Right now they lack any sort 
of link to source.


http://dlang.org/phobos/std_range.html#zip

For example, has no links anywhere to the source code except for 
the one link at the top, and that's just to the module. It 
doesn't specify the line that the function is defined at.

Re: New encryption block...

[Era Scarecrow via Digitalmars-d]

On Monday, 10 October 2016 at 03:15:07 UTC, sarn wrote:
End users won't want to permute+encrypt multiple times unless 
you can show there's a benefit in the speed/security tradeoff, 
so you'll need to think about that in the design.


 The largest portion would be that much like a hash, one small 
change will change the entire thing rather than a smaller portion 
(with the original blocksize). The multiple re-arranging and 
encryption steps is to ensure small changes affects every other 
block it was part of.


 Just thinking that if someone makes a database of say the first 
4 bytes expected in a file format (like gzip, bzip2, others, etc) 
then they can map most of the keys and immediately know how to 
decrypt it (assuming it's of a particular file/stream type). The 
larger block size also allows for multiple keys so you could push 
past far past the limitations of a single block cipher.


 As for a specific example, not really. Something fairly small, 
so personal documents and the like or archives, unlike say 
multi-media where it doesn't contain any personal data 
(probably). The only other idea is another multi-step process 
used for when generating hashes/keys or the like which is to slow 
down or make it annoyingly difficult to brute force passwords 
from a hashfile. Alternatively with the salting having it for 
encrypted communication would help hide sentences/replies where 
you reply the same thing over and over again.


Y>Do you have the stuff?
M>Yes
Y>Did you stash it in the place?
M>Yes
Y>Do you like Lasagna?
M>Yes

or something like that :P

 Oh well. My question was mostly an idea, having something to 
look over for block ciphers will be an interesting read (when I 
get to it)

Re: How do I load a shared library?

[Nafees via Digitalmars-d-learn]

anyone? so there is no way to get my 50,000 Line of code to work 
again? All that code to waste?


P.S: I've tried doing these:
Tried to use GDC, no luck
used -defaultlib=libphobos2.so, no luck
removed all functions from library, compiled it empty, yet, 
dlopen gives segFault.


AND:
This same code used to work on ubuntu 14.04 (i386), now I'm on 
xubuntu 16.04 (amd64).

Re: weighted round robin

[Marc Schütz via Digitalmars-d-learn]

On Saturday, 8 October 2016 at 22:48:53 UTC, vino wrote:

Hi,

 Can some one guide me on how to implement the weighted round 
robin, below is what i tried or any other better ways to do it


Main Requirement : Incoming socket connection has to be sent to 
3 servers in the weighted round robin fashion.


Prog:1
import std.stdio;
import std.range;
import std.range.primitives;

void main()
{
auto a = [1,2,3]; // E.g :Server Array
auto b = [1,2,3,4,5]; // E.g: Socket Array
auto r = roundRobin(a, b);
writeln(r);
}
OUTPUT : [1, 1, 2, 2, 3, 3, 4, 5]
Requirement : [1, 1, 2, 2, 3, 3,1,4,2,5]


auto r = roundRobin(a.cycle, b.cycle);

Beware though that this yields an infinite range. If you just 
need one round, you can use:


import std.algorithm.comparison : max;
writeln(r.take(max(a.length, b.length)));

Re: Beta 2.072.0-b2

[Sönke Ludwig via Digitalmars-d-announce]

There is an error [1] (caused by [2]) in taggedalgebraic, because void 
initializers for pointer types are now invalid in safe code. The 
question now is, is there any workaround that can be done in the 
library, or will every library user have to fix this?


Of course, the new error is more restrictive than it should be, namely 
if the uninitialized pointer field gets written before the first read, 
it would still be safe.


[1]: 
https://github.com/s-ludwig/taggedalgebraic/blob/2d9f9c537f9616bbe2a7072a9aa42ff1fd95f6d6/source/taggedalgebraic.d#L280
[2]: 
https://github.com/s-ludwig/taggedalgebraic/blob/2d9f9c537f9616bbe2a7072a9aa42ff1fd95f6d6/source/taggedalgebraic.d#L56

DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.

[Robert burner Schadek via Digitalmars-d-announce]

http://code.dlang.org/packages/dstatsd

StatsD allows to collect statistics about any application by 
using counters, gauges and more through UDP.


Usage:

auto s = new StatsD("127.0.0.1", 1234, ""); // connect to statsd 
server


s(Counter("Foo")); // increment counter "Foo"
s.inc("Bar"); // increment counter "Foo"

s(Counter("Args"), // send stats to Args, H, and timeA
  Counter("H", someIntValue),  // in one UDP message
  Timer("timeA", someTimeInMS)
);

{
  auto a = ScopeTimer("args", s); // automatic time collection
}

Re: color lib

[Manu via Digitalmars-d]

On 10 October 2016 at 17:29, Andrea Fontana via Digitalmars-d
 wrote:
> On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote:
>>
>> I've done another pass incorporating prior feedback, mostly focusing on
>> documentation.
>>
>>
>> http://dtest.thecybershadow.net/artifact/website-b6e2e44dd40dd7c70eb45829c02060b99ae3937b-57272ccdf902fa3f0c050d522129f2be/web/library-prerelease/std/experimental/color.html
>>
>> Can interested parties please give it another once-over and add
>> further comments?
>> How can I get this to a point where people would like to see it in phobos?
>>
>> Repo: https://github.com/TurkeyMan/color
>> PR: https://github.com/dlang/phobos/pull/2845
>
>
> Nice work!
>
> colorFromString should be colorFromRGBString :)

Nar. It parses any form of colour-in-a-string.

Re: When to call GC.{add,remove}Range in containers?

[Kagamin via Digitalmars-d-learn]

On Monday, 10 October 2016 at 07:12:10 UTC, Nordlöw wrote:

should not be scanned by the GC.


Shouldn't be a problem.

Re: dub command line in config?

[Seb via Digitalmars-d-learn]

On Sunday, 9 October 2016 at 20:03:58 UTC, WhatMeWorry wrote:

On Sunday, 9 October 2016 at 19:11:52 UTC, Jinx wrote:
On Sunday, 9 October 2016 at 08:52:55 UTC, rikki cattermole 
wrote:

On 09/10/2016 9:17 PM, Jinx wrote:

[...]


That is enough.
Mike Parker has presented a workaround that you can implement.
He has also shown how you can contact those that have the 
power to make this happen as you desire.


But as shown by other related issues[0], you may not get what 
you want.


[0] https://github.com/dlang/dub/issues/940


Yessim boss!  plez dunt hurt me! he shoed ma how too puck da 
cotton n giv me dis hur bag. I alredy no hew to puck da cotton 
n hud me own bag.


Hey Jinx.  Why don't you rename yourself to Jerk.


This is not a company - this is open source. I understand that 
one can be frustrated sometimes, but it should be kept in mind 
that all contributions happen voluntarily in people's free time. 
If you want something to be changed (and can't wait that someone 
does it in their free time), please submit a PR.

Re: Easy sockets - don't exist yet?

[Bauss via Digitalmars-d-learn]

Wrote some pretty simple sockets that you could use (Based on 
vibe.d though.)


https://github.com/bausshf/cheetah

Re: color lib

[Andrea Fontana via Digitalmars-d]

On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote:
I've done another pass incorporating prior feedback, mostly 
focusing on documentation.


http://dtest.thecybershadow.net/artifact/website-b6e2e44dd40dd7c70eb45829c02060b99ae3937b-57272ccdf902fa3f0c050d522129f2be/web/library-prerelease/std/experimental/color.html

Can interested parties please give it another once-over and add
further comments?
How can I get this to a point where people would like to see it 
in phobos?


Repo: https://github.com/TurkeyMan/color
PR: https://github.com/dlang/phobos/pull/2845


Nice work!

colorFromString should be colorFromRGBString :)

Re: Required DMD changes for Mir and few thoughts about D future

[Andrei Alexandrescu via Digitalmars-d]

On 10/10/16 2:05 AM, Martin Nowak wrote:

On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu wrote:

(after thinking a bit more) ... but Mir seems to rely in good part on
templates, which makes pre-compiled libraries less effective. -- Andrei


On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu wrote:
Ilya's answer
http://forum.dlang.org/post/rexuwvohqceaglcbr...@forum.dlang.org

Sounds like a feasible approach for phobos inclusion w/ prolly very
little usability restrictions on the generic API wrapping those.


Yes, after talking to him this seems definitely a worthwhile pursuit. -- 
Andrei

When to call GC.{add,remove}Range in containers?

[Nordlöw via Digitalmars-d-learn]

Which std.trait should be used to statically check whether I 
should call GC.{add,remove}Range on the elements of D containers?


`std.container.array.Array` currently uses `hasIndirections` but 
a comment on the same line says it should use `hasPointers` 
instead.


containers-em uses

template shouldAddGCRange(T)
{
import std.traits;
	enum shouldAddGCRange = isPointer!T || hasIndirections!T || is 
(T == class);

}

Quite some inconsistency here.

And what the case `Array!(Array!int))`? The wrapper Array!int 
contains contains a non-GC allocate pointer to ints and should 
not be scanned by the GC. Do we need another Container-trait for 
this? Or do we need to tag pointers with a special attribute that 
tells whether it has been allocated by GC or not.

Re: Problems with "shared"

[Satoshi via Digitalmars-d-learn]

On Sunday, 9 October 2016 at 21:32:23 UTC, ag0aep6g wrote:

On 10/09/2016 10:57 PM, jython234 wrote:

1. Where do I use the "shared" keyword?


What doesn't work is creating an unshared object of a class 
that only has a shared constructor. To create both shared and 
unshared objects, you need either two constructors or a `pure` 
one.


class C
{
this() pure {}
}
void main()
{
auto u = new C; /* works */
auto s = new shared C; /* too */
}




Why this ins't in doc? :O I didn't know about using pure in this 
way.

Re: __Symbol an alternative to recursive templates for type-introsecption

[Jacob Carlborg via Digitalmars-d]

On 2016-10-09 15:52, Stefan Koch wrote:


Walter would rather die. Then see ast-macros in D.


Yeah, unfortunately. Instead a lot of features are proposed and some 
implement that all could be implement using macros. At the same time 
complaining that macros are complex. That's making the language complex 
is implementing a lot of small features that could have been implemented 
with a generic solution instead.



I must say they would probably be worse then templates, in regards of
compile-time bloating.


It's difficult to say without implementing and testing it out.

--
/Jacob Carlborg

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu 
wrote:
(after thinking a bit more) ... but Mir seems to rely in good 
part on templates, which makes pre-compiled libraries less 
effective. -- Andrei


On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu 
wrote:

Ilya's answer
http://forum.dlang.org/post/rexuwvohqceaglcbr...@forum.dlang.org

Sounds like a feasible approach for phobos inclusion w/ prolly 
very little usability restrictions on the generic API wrapping 
those.

Re: Required DMD changes for Mir and few thoughts about D future

[Martin Nowak via Digitalmars-d]

On Saturday, 8 October 2016 at 18:10:14 UTC, Ilya Yaroshenko 
wrote:

https://github.com/MartinNowak/druntime/blob/23373260e65af5edea989b61d6660832fedbec15/src/core/internal/arrayop.d#L78.

Could you please give an example how it works for user?
I mean aligned vs unaligned.


???

You could pack them like so.
float4 vec = loadUnaligned!float4(ptrToFloats);
float4 vec = loadAligned!float4(ptrToFloats);

The wrappers are only necessary because DMD/GDC/ldc have 
different SIMD implementations. Would be great if someone wrote a 
common basis library, unfortunately Manu's std.simd got stuck in 
progress.


Does this is always inlined intrinsic (i mean this function has 
not any its machine code in the object file / library e.g. 
always inlined into the function body even in debug 
compilaiton)?


D doesn't have macros and can't force inline, to inline w/o 
inliner you could use mixin templates, but relying on the inliner 
to do it's job would be cleaner.