Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Stanislav Blinov via Digitalmars-d]

On Tuesday, 2 May 2017 at 02:51:02 UTC, Stanislav Blinov wrote:

Lost one else. Should be

 static if (traits & (AllocatorTraits.sharedInstance |
 AllocatorTraits.noGC))
 @nogc shared { mixin AllocatorInterface!(); }
 else static if (traits & AllocatorTraits.sharedInstance)
 shared { mixin AllocatorInterface!(); }
 else static if (traits & AllocatorTraits.noGC)
 @nogc { mixin AllocatorInterface!(); }
 else
 mixin AllocatorInterface!();

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Stanislav Blinov via Digitalmars-d]

On Monday, 1 May 2017 at 16:31:10 UTC, Nick Sabalausky (Abscissa) 
wrote:



If we had a type similar to TaggedAlgebraic...

Destroy?


It's too strict: you have to specify concrete types beforehand. 
This spills over into user code and makes it far less versatile 
that can be achieved.
Currently with allocators we have two extremes: IAllocator (and 
now, ISharedAllocator) that carries *no* static type information 
about concrete implementation, *and* loses all the inference 
regarding @nogc and shared memory. On the other end it's 
CAllocatorImpl that carries *both*.
But for user code, what is desirable is to have a middle man: a 
type that erases concrete allocator type but still keeps the 
@nogc and/or shared. This would enable user types to exchange 
their allocators while keeping static checks afforded by the 
language.

This can be done e.g. like this:

enum AllocatorTraits
{
none= 0x00,
noGC= 0x01,
sharedMemory= 0x02,
sharedInstance  = 0x04,
}

mixin template AllocatorInterface()
{
Ternary owns(Block block) @nogc;
Ternary resolveInternalPointer(void* p, ref Block result) 
@nogc;

Ternary empty() const @nogc;

Block allocate(size_t, TypeInfo ti = null);
Block alignedAllocate(size_t, uint);
Block allocateAll();
bool expand(ref Block, size_t);
bool reallocate(ref Block, size_t);
bool alignedReallocate(ref Block, size_t, uint);
bool deallocate(Block block);
bool deallocateAll();
}

template IAllocatorImpl(AllocatorTraits traits)
{
static if (traits & AllocatorTraits.sharedInstance)
alias Base = ISharedAllocator;
else
alias Base = IAllocator;

interface IAllocatorImpl : Base
{
static if (traits & AllocatorTraits.sharedMemory)
alias Block = shared(void)[];
else
alias Block = void[];

static if (traits & (AllocatorTraits.sharedInstance | 
AllocatorTraits.noGC))

@nogc shared { mixin AllocatorInterface!(); }
else static if (traits & AllocatorTraits.sharedInstance)
shared { mixin AllocatorInterface!(); }
else
@nogc { mixin AllocatorInterface!(); }

mixin AllocatorInterface!();
}
}

...and make the allocatorObject() function return 
IAllocatorImpl!traits instead of CAllocatorImpl!Allocator. With 
such IAllocatorImpl, user code can specify concrete expectations 
about the allocator without needing to know the exact allocator 
type.

Re: Porting Java code to D that uses << and >>> operators

[Era Scarecrow via Digitalmars-d-learn]

On Monday, 1 May 2017 at 21:04:15 UTC, bachmeier wrote:

On Monday, 1 May 2017 at 18:16:48 UTC, Era Scarecrow wrote:

 Reminds me... was the unsigned shift >>> ever fixed?


What was wrong with it?


Doing a broad test I'm seeing an issue with short & byte 
versions... Course that's probably due to the default upcasting 
to int rather than short/byte, while the >>>= works just fine. 
So...


byte f0 >> fff8
byte f0 >>> 7ff8
short f000 >> f800
short f000 >>> 7800

Re: alias this on module

[Jonathan Marler via Digitalmars-d]

On Monday, 1 May 2017 at 23:06:00 UTC, Petar Kirov [ZombineDev] 
wrote:
The common thing between modules and the other aggregate types 
(classes, interfaces, unions and structs) is that members of 
the former behave as if they were static members of the later. 
The difference, of course, is that since modules can have only 
static members, they can't be instantiated and by extension 
have no 'this' pointer/reference. Because of this I think 
'alias member this' on the module level would be nonsensical. 
Keep in mind that 'alias member this' is a tool for 
establishing a subtyping relationship - i.e. 'this' instance 
can be used wherever 'member' can be used - and not just a way 
to do member access rewrite like opDispatch. There is no 
subtyping relationship between namespaces, which is what 
modules are effectively​.


On the other hand, 'alias bar = foo.bar' and module level 
static opDispatch seem like perfectly reasonable and desirable 
features.


It's true that "this" normally refers to an instance of a type, 
but that's not the case with "alias this".  It's actually 
referring to the type itself, not an instance, so you can access 
static members through it.  I've written an example that compiles 
and works to demonstrate this:


import std.stdio;

struct Foo
{
int x;
}

struct fakemodule
{
// a member of the fake module
// Note that it has to be "static" to be analagous to a real 
module

static Foo foo;

// an "alias this" on the module (this isn't supported on a 
real module)

alias foo this;
}

void main()
{
fakemodule.x = 3; // references fakemodule.foo.x

// Print x using alias this and direct access
writeln(fakemodule.x);
writeln(fakemodule.foo.x);

// Verify these expressions represent the same thing
assert( == );
}

[Issue 17365] https://dlang.org/phobos/std_experimental_checkedint.html is missing the Throw hook description

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Keywords||bootcamp, preapproved

--

[Issue 17365] New: https://dlang.org/phobos/std_experimental_checkedint.html is missing the Throw hook description

[via Digitalmars-d-bugs]

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

  Issue ID: 17365
   Summary: https://dlang.org/phobos/std_experimental_checkedint.h
tml is missing the Throw hook description
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

The table enumerating the hooks omits Throw.

--

Re: Porting Java code to D that uses << and >>> operators

[Faux Amis via Digitalmars-d-learn]

Not sure if this is still the case. But this [1] suggests that D doesn't 
have an evaluation order defined but Java does.


[1] http://dsource.org/projects/dwt/wiki/Porting#Evaluationorder


To me, this [2] suggests otherwise ;)
Or am I missing something?

[2] https://dlang.org/spec/expression.html#order-of-evaluation

Re: alias this on module

[via Digitalmars-d]

On Monday, 1 May 2017 at 21:50:02 UTC, Jonathan Marler wrote:
On Monday, 1 May 2017 at 12:41:19 UTC, Steven Schveighoffer 
wrote:

On 4/30/17 7:59 PM, Jonathan Marler wrote:
On Sunday, 30 April 2017 at 23:44:32 UTC, Steven 
Schveighoffer wrote:

On 4/30/17 7:35 PM, Jonathan Marler wrote:
Any reason why "alias this" doesn't work at the module 
level?  If I
recall correctly, a module is really just a "class" under 
the hood, but

when I tried to use it I got:

Error: alias this can only be a member of aggregate, not 
module





public import is to modules as alias this is to 
structs/classes :)




They're actually different.

//
// File: mymodule.d
//
module mymodule;

struct Foo
{
int bar;
void baz();
}
__gshared Foo foo;
alias foo this; // using "alias this" on a module


So you want to alias a struct to a module? That's different 
than what I thought, I thought you wanted to alias one 
module's members into another.


I can't see a reason why it couldn't be added as a feature. I 
admit I'm not seeing the benefit though.


You could simulate this via a mixin. e.g.:

void baz()
{
   foo.baz;
}

@property ref bar()
{
   return foo.bar;
}

-Steve


Ya now you get it. It's not a big deal, it's just that after I 
thought about it, I couldn't think of a reason why it's not 
supported.  I actually have an application for it too.  Since 
modules are just classes under the hood, I was wondering if 
implementing it would be as simple as commenting out an error 
message like Andre's [nested import 
example](https://www.youtube.com/watch?v=3NihZVcZqto=183s

Re: parallel foreach

[Alex via Digitalmars-d-learn]

On Monday, 1 May 2017 at 13:24:55 UTC, Nicholas Wilson wrote:

Because staticIota expands to 0,1,2,3,4
so you are trying todo
foreach(i; parallel(0,1,2,3,4){}
which doesn't work.
try
foreach(i; parallel([staticIota!(0, 5)])){}
or
foreach(i; parallel(only(staticIota!(0, 5{}
not sure of the second one will work.


Ah thanks. Both versions work.

Re: [OT] Algorithm question

[MysticZach via Digitalmars-d]

On Monday, 1 May 2017 at 16:56:58 UTC, MysticZach wrote:
The goal is to have the first hit be the one you return. The 
method: if a random pick doesn't satisfy, randomly choose the 
partition greater than or less than based on 
uniform(0..array.length-1), and do the same procedure on that 
partition, reusing the random index to avoid having to call 
uniform twice on each recursion (one to choose a partition and 
one to choose an index within that partition). If the 
probability of choosing a partition is precisely proportional 
to the number of elements in that partition, it seems to me 
that the result will be truly random, but I'm not sure.


Now I'm questioning this, because if the positive cases are 
unevenly distributed, i.e., [11000100], the last one has 
about 50% chance to get picked instead of a 1 in 7 chance with my 
method. I guess you'd need to build a whole new array like the 
others are saying.

Re: alias this on module

[Jonathan Marler via Digitalmars-d]

On Monday, 1 May 2017 at 12:41:19 UTC, Steven Schveighoffer wrote:

On 4/30/17 7:59 PM, Jonathan Marler wrote:
On Sunday, 30 April 2017 at 23:44:32 UTC, Steven Schveighoffer 
wrote:

On 4/30/17 7:35 PM, Jonathan Marler wrote:
Any reason why "alias this" doesn't work at the module 
level?  If I
recall correctly, a module is really just a "class" under 
the hood, but

when I tried to use it I got:

Error: alias this can only be a member of aggregate, not 
module





public import is to modules as alias this is to 
structs/classes :)




They're actually different.

//
// File: mymodule.d
//
module mymodule;

struct Foo
{
int bar;
void baz();
}
__gshared Foo foo;
alias foo this; // using "alias this" on a module


So you want to alias a struct to a module? That's different 
than what I thought, I thought you wanted to alias one module's 
members into another.


I can't see a reason why it couldn't be added as a feature. I 
admit I'm not seeing the benefit though.


You could simulate this via a mixin. e.g.:

void baz()
{
   foo.baz;
}

@property ref bar()
{
   return foo.bar;
}

-Steve


Ya now you get it. It's not a big deal, it's just that after I 
thought about it, I couldn't think of a reason why it's not 
supported.  I actually have an application for it too.  Since 
modules are just classes under the hood, I was wondering if 
implementing it would be as simple as commenting out an error 
message like Andre's [nested import 

Re: Porting Java code to D that uses << and >>> operators

[bachmeier via Digitalmars-d-learn]

On Monday, 1 May 2017 at 18:16:48 UTC, Era Scarecrow wrote:

On Monday, 1 May 2017 at 15:53:41 UTC, Basile B. wrote:
It's the same code in D. It extracts consecutive bits in x12 
and x13 (and maskxx), put them at the beginning (right shift) 
and add them.


 Reminds me... was the unsigned shift >>> ever fixed?


What was wrong with it?

Re: Porting Java code to D that uses << and >>> operators

[bachmeier via Digitalmars-d-learn]

On Monday, 1 May 2017 at 19:06:36 UTC, Jacob Carlborg wrote:

Not sure if this is still the case. But this [1] suggests that 
D doesn't have an evaluation order defined but Java does.


[1] http://dsource.org/projects/dwt/wiki/Porting#Evaluationorder


That's good to know but shouldn't be an issue for this code.

"Rolling Hash computation" or "Content Defined Chunking"

[notna via Digitalmars-d-learn]

Hi Dlander's.

Found some interesting reads ([1] [2] [3]) about the $SUBJECT and 
wonder if there is anything available in the Dland?!


If yes, pls. share.
If not, how could it be done (D'ish)

[1] - 
https://moinakg.wordpress.com/2013/06/22/high-performance-content-defined-chunking/
- 
https://github.com/moinakg/pcompress/blob/master/rabin/rabin_dedup.c


[2] - 
https://restic.github.io/blog/2015-09-12/restic-foundation1-cdc


[3] - http://www.infoarena.ro/blog/rolling-hash

Thanks & regards

Re: The D ecosystem in Debian with free-as-in-freedom DMD

[Iain Buclaw via Digitalmars-d]

On 11 April 2017 at 23:02, Johannes Pfau via Digitalmars-d
 wrote:
> Am Tue, 11 Apr 2017 14:21:57 +
> schrieb Matthias Klumpp :
>
>> can be used by Automake
>> (native),
>
> Do you maintain D support for automake? I wrote some basic D support
> for autoconf and libtool
> (https://github.com/D-Programming-GDC/GDC/tree/master/libphobos/m4) but
> no automake support except for some hacks in
> https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/d_rules.am
>
> I guess I should upstream this some time.
>
> -- Johannes
>

Yeah, you should.  I upstreamed D support in DejaGNU back when I added
D tests to GDB.

https://www.mail-archive.com/dejagnu@gnu.org/msg00723.html

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Monday, 1 May 2017 at 19:02:11 UTC, H. S. Teoh wrote:
1) Suppose my base class has 3 ctors, and I only want my 
derived class to inherit 1 of them. Does this DIP allow for 
that?


Initially when designing the DIP I haven't thought about this 
use-case, but I've had more thought put into it recently. 
Unfortunately it came a bit late, but I thought about an 
alternate DIP design to this one, where instead of inheriting 
*all* base class ctors, the user would selectively inherit 
*specific* ctors. The alternate proposal is just a PR for now: 
https://github.com/dlang/DIPs/pull/60 (direct link 
https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md)


2) If my derived class has no ctors (and the base class has a 
default ctor but also several other ctors), what if I want to 
suppress inheriting base class ctors (except the default)?  Do 
I need to individually list all base class ctors and attach 
@disable to them? How would this interact with future-proofing 
my derived class in case the base class changes in the future 
(e.g., more ctors got added)?


Very good question, especially about future-proofing. This goes 
back to my response to #1, and makes me think that in fact the 
alternate design in https://github.com/dlang/DIPs/pull/60 is 
probably a better idea.


3) Is it legal to write `@disable this(int,int)` when the base 
class doesn't have a matching ctor?  This might happen, e.g., 
if the base class ctor was removed after the fact.  Or would 
all derived classes that disabled the original ctor have to be 
updated?


It would have to be illegal.

4) If my derived class has no (explicit) ctors, is there any 
semantic

difference between writing:

class Derived : Base {}

vs.:

class Derived : Base { alias super.this this; }
?


There shouldn't be any semantic difference.

Would it be better to require the latter explicit form so that 
this DIP is opt-in (and also prevents breaking existing code 
that uses compile-time introspection)?


I'm not really sure of real-world examples where this would be 
the case, where a class designer has explicitly derived from a 
class but failed to write any constructors *and* intends for that 
class not to be constructible. In such a case, surely the 
designer of the class would label the class as `abstract`.


Or would the added boilerplate (have to write that alias line 
for all derived classes) make this DIP less attractive? (Note 
that this essentially nullifies implicit ctor inheritance, 
which is one of main points of this DIP. But the point is that 
alternatives like this should be considered and argued against 
to make this DIP stronger.)


I feel like implicit constructor inheritance where there are no 
new additional constructors being introduced in the derived class 
would be a safe default to have. I can't imagine a case where 
this would cause bugs in user code. But I'm open to seeing such 
examples, of course.


5) How would this DIP interact with access controls? E.g., if 
the base class has a private ctor, will that be inherited 
implicitly? Or if the base class has a protected ctor, will the 
inherit ctor remain as protected?


Not unless the two classes were part of the same module (and thus 
had symbol visibility). However the implicitly inherited 
constructor would also be private in the derived class as well, 
so that should answer the second part of that question.


Will there be a way to inherit a base class protected ctor and 
make it public instead? (I.e., a form of forwarding, from a 
public derived class ctor to a protected base class ctor.)


Interesting idea. That would be another point for the alternate 
proposal in 
https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md, which would allow code such as:


class A { protected this ( int x ) { } }
class B { public alias super.this(int) this; }

If the base class introduces new private ctors, will that cause 
any problems with derived classes implicitly inheriting all 
ctors (assuming they do inherit private ctors)?


At what point does it cross the line of requiring explicit 
declaration of a forwarding ctor in the derived class?


It's hard to tell whether it would cause problems, although it is 
indeed possible to accidentally inherit a ctor even if it's 
unwanted.


I see the general sentiment, and I think the big question to be 
asked here is: do we want a way to inherit "everything at once", 
or have a simple syntax to selectively inherit some constructors 
as in 
https://github.com/AndrejMitrovic/DIPs/blob/d4ae8866d52f1a17a5c4ff9f2c843d61dad5e7e7/DIPs/DIP1004-alternative.md.

[Issue 17361] latest windows 10 insider preview and dmd no longer runs.

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #2 from ZombineDev  ---
What is the exact version of the build? I'm also using the Insider Preview of
Windows 10 (though I am on the slow update ring) and (at least) on version
1703, build 15063.138 I have no trouble running DMD.

Also, can you check if Windows Defender isn't mistaking the compiler for a
virus (e.g. by white-listing it or temporary disabling the protection)? There
have been some reports about certain anti-virus/malware programs wrongly
detecting dmd as such, though I don't think Windows Defender has been mentioned
before.

Finally, can you give some more information on how are you running dmd? Command
Prompt, PowerShell, Windows Subsystem for Linux (bash.exe), MinGW or some IDE?
Is there some error message or backtrace that gets printed? Also does dub run
ok? (You can testing by fetching a package - e.g. 'dub fetch dscanner'.)

--

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Monday, 1 May 2017 at 18:34:43 UTC, H. S. Teoh wrote:
so the fact that they now have different syntaxes was seen as 
an advantage.


Yeah, I remember that decision. I don't think I've ever agreed 
with it, though. :o)


We'll see.. I don't personally find it very important, I'm fine 
with either styles of syntax.

Re: DMD VS2017 Support

[Igor via Digitalmars-d]

On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:


VS 2017 uses a "private" registry that the Visual D installer 
doesn't have access to. I'll change the registry location in 
the next release.


Please note that the next dmd installer will also detect VS2017 
and setup directories correctly in sc.ini: 
https://github.com/dlang/installer/pull/227


That is great news! Thanks for quick response.

Re: DConf Hackathon Ideas

[Jacob Carlborg via Digitalmars-d]

On 2017-05-01 16:51, Mike Parker wrote:


I love SDL and much prefer it over JSON for DUB configs. Use it for all
of my D projects. It looks cleaner and supports comments. I really would
hate to see support dropped.


+1

I would be fine with YAML as well.

--
/Jacob Carlborg

Re: [OT] Algorithm question

[MysticZach via Digitalmars-d]

On Monday, 1 May 2017 at 16:56:58 UTC, MysticZach wrote:

   // choose a random partition proportionally
   auto j = uniform(da.length - 1);
   if (j < i) {
  // the lower partition
  int a = randomlySatisfyImpl(da[0..i], j);
  if (a != -1) return a;
  else return randomlySatisfyImpl(da[i+1 .. da.length], j - 
(i + 1));

   }
   else {
  // higher partition, investigate in reverse order
  int a = randomlySatisfyImpl(da[i+1 .. da.length], j - (i 
+ 1));

  if (a != -1) return i +1 + a;
  else return i + 1 + randomlySatisfyImpl(da[0..i], j);


The line above has a bug. Replace it with:

   else {
  a = randomlySatisfyImpl(da[0..i], j);
  return (a == -1) ? -1 : i + 1 + a;
   }


   }
}


But the idea's the same. Hopefully it's clear.

Re: CTFE Status 2

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 06:23:08PM +, Stefan Koch via Digitalmars-d wrote:
> On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote:
> > On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via Digitalmars-d
> > wrote:
> > > On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > > > [ ... ]
> > > 
> > > Big news!  The first step to include debug info has been done.
> > > 
> > > Yes this means you will be able to step through ctfe code while
> > > the compiler executes it.
> > 
> > Wow! Will that be accessible to users in the end?  That could be a
> > totally awesome way of debugging CTFE code!
> > 
> > 
> > T
> 
> Yes the plan is to make it accessible for the advanced user.  probably
> with a really bad ui, though (since I am awful at UI code).

I'm not sure about providing a debugger UI inside the compiler itself...
it's certainly possible, and could lead to interesting new ways of using
a compiler, but I was thinking more along the lines of providing the
necessary hooks so that you could attach an external debugger to the
CTFE engine.

But if the debugger UI is simple enough, perhaps having it built into
the compiler may not be a bad thing. It would also avoid potential
trouble caused by some platforms not having debuggers capable of
plugging into the compiler in that way.  But still, I can see people
demanding IDE integration for this eventually... :-O


T

-- 
Obviously, some things aren't very obvious.

Re: DIP 1004 Preliminary Review Round 1

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 02:55:28PM +, Mike Parker via Digitalmars-d wrote:
> DIP 1004 is titled "Inherited Constructors.
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md
[...]

I'm appalled that the only discussion that has come up so far is related
to syntax rather than semantics. ;-)

Overall, I like this DIP. Reducing boilerplate is always a good thing
IMO, and is one of the things that attracted me to D in the first place.

That said, there are a few points I feel could be more thoroughly
explored:

1) Suppose my base class has 3 ctors, and I only want my derived class
to inherit 1 of them. Does this DIP allow for that?

2) If my derived class has no ctors (and the base class has a default
ctor but also several other ctors), what if I want to suppress
inheriting base class ctors (except the default)?  Do I need to
individually list all base class ctors and attach @disable to them? How
would this interact with future-proofing my derived class in case the
base class changes in the future (e.g., more ctors got added)?

3) Is it legal to write `@disable this(int,int)` when the base class
doesn't have a matching ctor?  This might happen, e.g., if the base
class ctor was removed after the fact.  Or would all derived classes
that disabled the original ctor have to be updated?

4) If my derived class has no (explicit) ctors, is there any semantic
difference between writing:

class Derived : Base {}

vs.:

class Derived : Base { alias super.this this; }

?  Would it be better to require the latter explicit form so that this
DIP is opt-in (and also prevents breaking existing code that uses
compile-time introspection)?  Or would the added boilerplate (have to
write that alias line for all derived classes) make this DIP less
attractive? (Note that this essentially nullifies implicit ctor
inheritance, which is one of main points of this DIP. But the point is
that alternatives like this should be considered and argued against to
make this DIP stronger.)

5) How would this DIP interact with access controls? E.g., if the base
class has a private ctor, will that be inherited implicitly?  Or if the
base class has a protected ctor, will the inherit ctor remain as
protected?  Will there be a way to inherit a base class protected ctor
and make it public instead? (I.e., a form of forwarding, from a public
derived class ctor to a protected base class ctor.)

If the base class introduces new private ctors, will that cause any
problems with derived classes implicitly inheriting all ctors (assuming
they do inherit private ctors)?

At what point does it cross the line of requiring explicit declaration
of a forwarding ctor in the derived class?


T

-- 
Just because you can, doesn't mean you should.

Re: Porting Java code to D that uses << and >>> operators

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-05-01 17:45, bachmeier wrote:

I'm porting a small piece of Java code into D, but I've run into this:

int y1 = ((x12 & MASK12) << 22) + (x12 >>> 9) + ((x13 & MASK13) << 7) +
(x13 >>> 24);

I have a basic understanding of those operators in both languages, but I
can't find a sufficiently detailed explanation to tell me how to
translate the Java into D and know that it's guaranteed to give the same
result. Can someone tell me the correct D code to use?


Not sure if this is still the case. But this [1] suggests that D doesn't 
have an evaluation order defined but Java does.


[1] http://dsource.org/projects/dwt/wiki/Porting#Evaluationorder

--
/Jacob Carlborg

[Issue 17364] New: Difference between slicing a slice and a reference to a slice

[via Digitalmars-d-bugs]

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

  Issue ID: 17364
   Summary: Difference between slicing a slice and a reference to
a slice
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ki...@gmx.net

DMD treats these 2 cases differently, while GDC works as expected and LDC is
being fixed accordingly:

```
@safe:

int[] globalArray;

ref int[] getSliceRef() { return globalArray; }

int getLowerBound()
{
globalArray = [ 666 ];
return 0;
}

void main()
{
globalArray = [ 1 ];
auto r1 = globalArray[getLowerBound() .. $];
assert(r1 == [ 666 ]);

globalArray = [ 1 ];
auto r2 = getSliceRef()[getLowerBound() .. $];
assert(r2 == [ 1 ]); // BUG, should be [ 666 ]
}
```

--

Re: DIP 1004 Preliminary Review Round 1

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 04:08:36PM +, Andrej Mitrovic via Digitalmars-d 
wrote:
> On Monday, 1 May 2017 at 15:33:47 UTC, Basile B. wrote:
> > On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:
> > > DIP 1004 is titled "Inherited Constructors. [...]
> > > All review-related feedback on and discussion of the DIP should
> > > occur in this thread. [...]
> > > Destroy!
> > 
> > An obvious omission in the syntax variations [1]
> > 
> > - alias this() = super.this();
> > 
> > or
> > 
> > - alias this = super.this;
> 
> I thought people would catch on that this is implied. :) The old-style
> or new-style alias syntax should both be allowed, in my opinion. The
> main issue is what to do about the parentheses, whether to include
> them or not.

I don't think new-style syntax is supported for `alias X this;`. I
vaguely remember in the original discussions when new-style alias syntax
was first introduced, that we decided against allowing `alias this = X;`
because alias this held a special meaning that's different from the
usual alias declaration, so the fact that they now have different
syntaxes was seen as an advantage.


T

-- 
Тише едешь, дальше будешь.

Re: DConf Hackathon Ideas

[Stefan Koch via Digitalmars-d]

On Monday, 1 May 2017 at 17:04:42 UTC, Iain Buclaw wrote:
On 1 May 2017 at 16:51, Mike Parker via Digitalmars-d 
 wrote:
On Monday, 1 May 2017 at 14:38:11 UTC, Joseph Rushton Wakeling 
wrote:


On Thursday, 27 April 2017 at 16:33:02 UTC, singingbush wrote:


SDL should be dropped.



Deprecated, sure.  But dropping it seems a bad idea given 
that various projects do still use it for their DUB package 
config.



NOBODY USES IT!



Probably not true.  Perhaps a hackathon project could be to 
create a little app to find which projects on GitHub (or at 
least code.dlang.org) still use a `dub.sdl`, and auto-submit 
a PR to fix that? :-)



I love SDL and much prefer it over JSON for DUB configs. Use 
it for all of my D projects. It looks cleaner and supports 
comments. I really would hate to see support dropped.


We should make XML the default config format for DUB.



http://code.dlang.org/;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
  description="The vibe.d server application running 
gdcproject.org."

copyright="Copyright © 2014, Iain Buclaw">

  


  
  


  

  



/Runaway!


You forgot a few / there

[Issue 17363] New: @safety hole due to $ caching in slice expressions

[via Digitalmars-d-bugs]

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

  Issue ID: 17363
   Summary: @safety hole due to $ caching in slice expressions
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ki...@gmx.net

When loading and caching $ once for a slice expression before evaluating the
bounds expressions, it isn't updated due to potential side effects on the
slicee when evaluating upper and lower bounds expressions, leading to invalid
bounds checks and memory corruption potential in @safe code:

```
@safe:

int[] globalArray;

int getLowerBound()
{
globalArray = [ 666 ];
return 0;
}

void main()
{
globalArray = new int[256];
auto r = globalArray[getLowerBound() .. $];
assert(r[0] == 666);
assert(r.length == 256); // BUG, should be 1
r[] = 123; // oops
}
```

GDC and LDC don't cache $ and thus don't suffer from this issue.

--

Re: DMD VS2017 Support

[Rainer Schuetze via Digitalmars-d]

On 01.05.2017 10:03, Igor wrote:

On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:

On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:


I should also mention that compiling using DUB works. It only doesn't
work from VS.


Check your VisualD settings and make sure it has DMD path set up.
See under Tools>Options>Projects and solutions>Visual D Settings


That was it. It didn't occur to me that this was the problem because I
payed closed attention during VisualD installation and saw it properly
recognized where DMD was installed but for some reason the path wasn't
set in Options. Once I did set it, compile and build worked. Thanks
evilrat!

So in conclusion it seems the problem is in VisualD installation which
doesn't set the path properly even though it recognizes where DMD is
installed. Hope the author takes a look at this problem so beginners
wanting to try D don't give up on a problem like this.


VS 2017 uses a "private" registry that the Visual D installer doesn't 
have access to. I'll change the registry location in the next release.


Please note that the next dmd installer will also detect VS2017 and 
setup directories correctly in sc.ini: 
https://github.com/dlang/installer/pull/227

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote:
On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via 
Digitalmars-d wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
wrote:

> [ ... ]

Big news!
The first step to include debug info has been done.

Yes this means you will be able to step through ctfe code 
while the compiler executes it.


Wow! Will that be accessible to users in the end?  That could 
be a totally awesome way of debugging CTFE code!



T


Yes the plan is to make it accessible for the advanced user.
probably with a really bad ui, though (since I am awful at UI 
code).

Re: Porting Java code to D that uses << and >>> operators

[Era Scarecrow via Digitalmars-d-learn]

On Monday, 1 May 2017 at 15:53:41 UTC, Basile B. wrote:
It's the same code in D. It extracts consecutive bits in x12 
and x13 (and maskxx), put them at the beginning (right shift) 
and add them.


 Reminds me... was the unsigned shift >>> ever fixed?

Re: DConf Hackathon Ideas

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 06:02:53PM +, Moritz Maxeiner via Digitalmars-d 
wrote:
> On Monday, 1 May 2017 at 17:04:42 UTC, Iain Buclaw wrote:
> > [...]
> > 
> > We should make XML the default config format for DUB.
> > 
> > [...]
> > 
> > /Runaway!
> 
> Well, at least nearly everyone hates XML equally, which may be an
> indicator of a good compromise.

Whoa.  XML for DUB?  That may just be the final nail in the coffin for
me ever picking up DUB in this lifetime. ;-)


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada

Re: DConf Hackathon Ideas

[Moritz Maxeiner via Digitalmars-d]

On Monday, 1 May 2017 at 17:04:42 UTC, Iain Buclaw wrote:

[...]

We should make XML the default config format for DUB.

[...]

/Runaway!


Well, at least nearly everyone hates XML equally, which may be an 
indicator of a good compromise.

Re: DConf Hackathon Ideas

[Joakim via Digitalmars-d]

On Thursday, 27 April 2017 at 14:53:02 UTC, Mike Parker wrote:
This year, DConf has an extra day tacked on for problem solving 
in the form of a hackathon. The intent is to work on issues 
people find frustrating in the D ecosystem. While there will be 
time given at the event for proposals, and those involving 
third-party projects are welcome, it will help speed things 
along for the organizers to come in with a list of big issues 
to get the ball rolling.


To help in compiling the list, what are some major issues from 
the ecosystem that you'd like to see fixed?


Probably the plan anyway, but my suggestion would be for the core 
team to not hack on anything, but spend the time discussing 
issues that have been discussed to death online but not resolved, 
such as some devs not agreeing with Walter and the DIP 1000 path 
he's taking.


Use the in-person time to get some heavy bandwidth on those 
issues and try to make sure the differences are hashed out.  
There may not be a final agreement on the solution, but there 
certainly shouldn't be any more misunderstanding of the proposed 
options.


For people not on the core team, they can hack on a lot of the 
stuff mentioned in this thread, perhaps after coordinating with 
the core team about what's really needed and how to go about 
doing it.


Great idea, btw, to set aside a day just for this.

Re: [OT] Algorithm question

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 02:38:09PM +, Ivan Kazmenko via Digitalmars-d wrote:
> On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
> > Given a set A of n elements (let's say it's a random-access range of
> > size n, where n is relatively large), and a predicate P(x) that
> > specifies some subset of A of elements that we're interested in,
> > what's the best algorithm (in terms of big-O time complexity) for
> > selecting a random element x satisfying P(x), such that elements
> > that satisfy P(x) have equal probability of being chosen? (Elements
> > that do not satisfy P(x) are disregarded.)
> 
> I'd like to note here that, if you make use of the same P(x) many
> times (instead of different predicates on each call), it makes sense
> to spend O(n) time and memory filtering by that predicate and storing
> the result, and then answer each query in O(1).

Unfortunately, P(x) could be different each time (sorry, should have
stated this explicitly), and A may also change in between calls to this
random selection algorithm.  So filtering would not be a good approach.


[...]
> There are actually two variations of Fisher-Yates shuffle:
> (https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle)
> 
> 1.
> auto p = n.iota.array;
> foreach (pos; 0..n) {
> auto otherPos = uniform (0, pos + 1);
> swap (p[pos], p[otherPos]);
> }
> 
> When we look at this after k-th iteration, the first k elements are
> randomly and uniformly permuted, and the rest (n-k) are left
> untouched.
> 
> 2.
> auto p = n.iota.array;
> foreach (pos; 0..n) {
> auto otherPos = uniform (pos, n);
> swap (p[pos], p[otherPos]);
> }
> 
> When we look at this after k-th iteration, the first k elements are a
> random combination of all n elements, and this combination is randomly
> and uniformly permuted.  So, the second variation is what we need:
> each new element is randomly and uniformly selected from all the
> elements left.  Once we get the first element satisfying the
> predicate, we can just terminate the loop.  If there are m out of n
> elements satisfying the predicate, the average number of steps is n/m.

But wouldn't creating the array p already be O(n)? Albeit, somewhat
faster than n iterations of the main loop since copying iota ought to be
somewhat cheaper than generating a random number and swapping two
elements.


> Now, the problem is that both of these allocate n "size_t"-s of memory
> to start with.  And your problem does not allow to shuffle the
> elements of the original array in place, so we do need an external
> permutation for these algorithms.  However, there are at least two
> ways to mitigate that:
> 
> (I)
> We can allocate the permutation once using n time and memory, and
> then, on every call, just reuse it in its current state in n/m time.
> It does not matter if the permutation is not identity permutation: by
> symmetry argument, any starting permutation will do just fine.

I like this idea very much. This lets us only pay once for creating the
index array, and reuse it almost "for free" thereafter.

Still, the O(n) space requirement could potentially be onerous, since n
is expected to be rather large.


> (II)
> We can store the permutation p in an associative array instead of a
> regular array, actually storing only the elements accessed at least
> once, and assuming other elements to satisfy the identity p[x] = x.
> So, if we finish in n/m steps on average, the time and extra memory
> used will be O(n/m) too.  I can put together an example implementation
> if this best satisfies your requirements.
[...]

This is interesting, and relaxes the O(n) space requirement initially.
After enough queries, though, I'd expect the AA to eventually grow to n
elements (as there is a chance some queries will end up finding no
elements that satisfy P(x) so it would generate the entire permutation).

But I like your idea of reusing the index array.  It's definitely a
possibility!


T

-- 
Your inconsistency is the only consistent thing about you! -- KD

Re: [OT] Algorithm question

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 12:31:48PM +, Andrea Fontana via Digitalmars-d 
wrote:
> On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
> > 1) "Random shooting":
> > 
> > auto r = ... /* elements of A */
> > for (;;) {
> > auto i = uniform(0, r.length);
> > if (P(r[i])) return r[i];
> > }
> > 
> >Advantages: If a large percentage of elements in A satisfy P(x), then
> >the loop will terminate within a small number of iterations; if the
> >majority of elements satisfy P(x), this will terminate well below n
> >iterations.
> > 
> >Disadvantages: If only a small percentage of elements satisfy P(x),
> >then this loop could take arbitrarily long to terminate, and it will
> >not terminate at all if no elements satisfy P(x).
> > 
> 
> If you find an element that doesn't satisfy P(x) move it on top of array
> (swap!) and then try again with uniform(1, r.length - 1) and so on.
> 
> It terminates in this way.
[...]

The problem is that swapping elements is not allowed for this particular
problem.  If swapping was allowed this would be a much easier problem to
solve. :-)


T

-- 
Chance favours the prepared mind. -- Louis Pasteur

Re: [OT] Algorithm question

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 11:32:19AM +, Mike B Johnson via Digitalmars-d 
wrote:
[...]
> Since most real world problems would require selecting elements more
> than once it may be far more efficient to sort by P(x)(filter) then
> simply select a random element.
> 
> e.g.,
> 
> a = A.filter(x->P(x))  // Creates a new set a where only the elements
> of A that satisfy P(x) are added
> 
> ...
> 
> e = a.random;
> 
> 
> this is O(1) if you only have to filter once(you can create a
> container that always "sorts" on P(x) so to speak.. like a sorted
> dictionary).
[...]

Sorry, I forgot to specify that P(x) may change each time, as may the
input A. So caching would be of little help in this case.


T

-- 
This is a tpyo.

Re: [OT] Algorithm question

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 08:42:05AM +, John Colvin via Digitalmars-d wrote:
[...]
> You can recover O(n) calls to P by caching the results.

Sorry, I forgot to specify that P(x) can be different each time.

Also, the input A may also be different each time, albeit remain the
same length (though the expectation is that it will be mostly the same
-- not that it matters, though, I don't think any of the proposed
solutions here count on that).


> You can recover O(n) for both P and rng by progressively removing
> elements from r or any other method that results in an easily
> samplable set of all elements of r not yet visited (and therefore
> possible candidates).
[...]

Yes, I realize that if r was mutable, there are existing simple
solutions. The problem is that it's not mutable, or rather, should not
be mutated by this selection algorithm.


[...]
> Yes. As a matter of fact it would be the logical extension of my
> algorithm above for when you can't or don't want to change r (again,
> only just thought of this, untested...):
> 
> auto r = ... /* elements of A */
> auto indices = iota(r.length).array;
> auto nRemaining = r.length;
> while (nRemaining) {
>   auto i = uniform(0, nRemaining);
>   if (P(r[indices[i]])) return r[indices[i]];
>   else swap(indices[i], indices[--nRemaining]);
> }
> 
> You could also do the same thing but with an array of pointers to
> elements of r instead of indices.

The trouble with this is that you have to allocate an array of indices,
and r.length is rather large, so creating this array is O(n) each time.
But I think Ivan Kazmenko has an excellent idea to cache this index
array. Since, by symmetry, it doesn't matter if the starting indices
array was the identity permutation, we could just initialize this array
once, and the next time just skip to the loop directly (reusing the
previous (possibly partially) permuted indices as the starting point).
It does require O(n) memory, which is unfortunate, but at least we only
pay for that once.

I was hoping for something more along the lines of a random permutation
algorithm with sublinear (if not O(1)) space complexity that can return
elements of the permutation consecutively on-demand, like a lazy range.
Something along the lines of:

auto seed = ... /* get random number */
auto lazyRange = generatePermutation(seed, n);

where generatePermutation is some incremental algorithm that produces a
unique permutation of 0 .. n per seed value. Ideally, this algorithm
would only do as much work as is necessary to produce the first k
elements of the permutation, so that if the main loop terminates early
(we found an element satisfying P(x)) we don't waste time generating the
rest of the permutation.


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured 
megaliths that address all questions by piling on ridiculous internal links in 
forms which are hideously over-complex." -- Simon St. Laurent on xml-dev

Re: DConf Hackathon Ideas

[Iain Buclaw via Digitalmars-d]

On 1 May 2017 at 16:51, Mike Parker via Digitalmars-d
 wrote:
> On Monday, 1 May 2017 at 14:38:11 UTC, Joseph Rushton Wakeling wrote:
>>
>> On Thursday, 27 April 2017 at 16:33:02 UTC, singingbush wrote:
>>>
>>> SDL should be dropped.
>>
>>
>> Deprecated, sure.  But dropping it seems a bad idea given that various
>> projects do still use it for their DUB package config.
>>
>>> NOBODY USES IT!
>>
>>
>> Probably not true.  Perhaps a hackathon project could be to create a
>> little app to find which projects on GitHub (or at least code.dlang.org)
>> still use a `dub.sdl`, and auto-submit a PR to fix that? :-)
>
>
> I love SDL and much prefer it over JSON for DUB configs. Use it for all of
> my D projects. It looks cleaner and supports comments. I really would hate
> to see support dropped.

We should make XML the default config format for DUB.



http://code.dlang.org/;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
  

  


  
  


  

  



/Runaway!

Re: [OT] Algorithm question

[MysticZach via Digitalmars-d]

On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
Given a set A of n elements (let's say it's a random-access 
range of

size n, where n is relatively large), and a predicate P(x) that
specifies some subset of A of elements that we're interested 
in, what's
the best algorithm (in terms of big-O time complexity) for 
selecting a
random element x satisfying P(x), such that elements that 
satisfy P(x)
have equal probability of being chosen? (Elements that do not 
satisfy

P(x) are disregarded.)


Here's how I would do it:

// returns a random index of array satisfying P(x), -1 if not 
found

int randomlySatisfy(A[] array) {
   if (array.length == 0)
  return -1;
   int i = uniform(0, array.length);
   return randomlySatisfyImpl(array, i);
}

// recursive function
private int randomlySatisfyImpl(A[] da, int i) {
   if (P(da[i]))
  return i;
   if (da.length == 1)
  return -1;

   // choose a random partition proportionally
   auto j = uniform(da.length - 1);
   if (j < i) {
  // the lower partition
  int a = randomlySatisfyImpl(da[0..i], j);
  if (a != -1) return a;
  else return randomlySatisfyImpl(da[i+1 .. da.length], j - 
(i + 1));

   }
   else {
  // higher partition, investigate in reverse order
  int a = randomlySatisfyImpl(da[i+1 .. da.length], j - (i + 
1));

  if (a != -1) return i +1 + a;
  else return i + 1 + randomlySatisfyImpl(da[0..i], j);
   }
}

The goal is to have the first hit be the one you return. The 
method: if a random pick doesn't satisfy, randomly choose the 
partition greater than or less than based on 
uniform(0..array.length-1), and do the same procedure on that 
partition, reusing the random index to avoid having to call 
uniform twice on each recursion (one to choose a partition and 
one to choose an index within that partition). If the probability 
of choosing a partition is precisely proportional to the number 
of elements in that partition, it seems to me that the result 
will be truly random, but I'm not sure.

Re: DConf Hackathon Ideas

[Mike Parker via Digitalmars-d]

On Monday, 1 May 2017 at 15:36:16 UTC, bachmeier wrote:

On Monday, 1 May 2017 at 14:51:19 UTC, Mike Parker wrote:

I love SDL and much prefer it over JSON for DUB configs. Use 
it for all of my D projects. It looks cleaner and supports 
comments. I really would hate to see support dropped.


I'm not even sure what it would mean to "drop" support for SDL. 
As long as someone decides to support it, it will be supported. 
SDL to my knowledge is not an "official" D project.


Well, sure, but we were specifically talking about support in DUB.

http://forum.dlang.org/post/eejeorhqgwxbduunm...@forum.dlang.org

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/30/2017 05:39 PM, Andrei Alexandrescu wrote:

The allocators design is interesting in that it has a full DbI core, on
top of which resides a thin dynamically-type interface (IAllocator and
ISharedAllocator). We're still exploring the idioms enabled by this
interaction. -- Andrei


I assume this dual-interface design (DbI + OO) is, much like std.digest, 
a way to have our template/DbI cake and still permit things to be 
selected at runtime too (via OO), right?


If so, this is a topic that's been on my mind lately, and I'd like to 
offer some thoughts I've had (well, some partial thoughts anyway):


Part A: While I like that the std.digest design allows both DbI and 
runtime-selection of arbitrary user-created types, it has a few issues:


1. It feels awkward that it needs essentially duplicate APIs under two 
different paradigms to pull it off.


2. If a library (such as mine) wants to support both versions, then it 
needs a little bit of extra plumbing to accommodate that. Or at least it 
seemed to in my case. (std.digest itself even has a little bit of extra 
plumbing because of it: WrapperDigest)


3. The OO version, being OO, does involve some type erasure.

Now, fast-forward to:

Part B: On a separate project, I've used Sonke's TaggedAlgebraic before 
. It's kind of interesting: 
It's much like Phobos's Algebraic, except it allows function/member 
forwarding to the current underlying value *without* having to 
explicitly check what the current value's type is (Don't recall offhand 
exactly how it handles members that don't exist on the current type, 
probably throws I guess, although I'd imagine it would be possible to 
statically disallow access to members known at compile-time to not exist 
in *any* of the possible underlying types. But I digress).


But then:

Part C: At the time, I saw TaggedAlgebraic's member-forwarding as a 
minor little convenience feature. But the other day I was working with 
some code that used and built upon std.digest, and something occurred to me:


If we had a type similar to TaggedAlgebraic, but was an open variant 
rather than a closed algebraic (Ie, a type like Phobos's Variant, but 
forwarded member access without first requiring explicit conversion to 
the exact underlying type), then *that* could be used to permit 
runtime-selection between arbitrary DbI types *without* the type-erasure 
and "duality" of adding in OO (or at least, less type-erasure anyway). 
Just maybe need the ability to filter the allowable types via a 
constraint (such as isBidirctionalRange, etc), and then, IIUC it should 
be possible for the variant-like supertype to qualify as an 
honest-to-goodness instance of the DbI interface. Voila: OO has been 
obsoleted.


Destroy?

Re: What are we going to do about mobile?

[Iain Buclaw via Digitalmars-d]

On 1 May 2017 at 18:18, Iain Buclaw  wrote:
> On 1 May 2017 at 17:47, Johannes Pfau via Digitalmars-d
>  wrote:
>> Am Mon, 1 May 2017 14:44:35 +0200
>> schrieb Iain Buclaw via Digitalmars-d :
>>
>>> On 1 May 2017 at 14:40, Iain Buclaw  wrote:
>>> > So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)
>>>
>>> With the latter also testing all crosses we can do (there are 18
>>> different gdc cross-compilers in Ubuntu, for 12 distinct
>>> architectures).
>>
>> BTW is there some documentation on how to update / rebuild these
>> debian / ubuntu packages with updated GDC sources?
>>
>> -- Johannes
>>
>
> Doubt it, the debian source packages are quite complex too - though
> there's only a few places that need changing, once you work out
> exactly *where*.
>
> As you're just updating GDC sources, it should just be a case of
> replacing the gdc tarball with a new copy, and the rest is already
> handled.

Though for the purpose of CI, we could either build the toolchain
ourselves - either using https://crosstool-ng.github.io, or re-use the
existing cross toolchains in Ubuntu - in both cases, cache the
finished set-up in a docker image.  Building GDC would be still done
by hand just to keep things simple, which should only be a case of
configuring the correct host and target triplet (or maybe
http://build-gdc.readthedocs.io :-)

Re: What are we going to do about mobile?

[Iain Buclaw via Digitalmars-d]

On 1 May 2017 at 17:47, Johannes Pfau via Digitalmars-d
 wrote:
> Am Mon, 1 May 2017 14:44:35 +0200
> schrieb Iain Buclaw via Digitalmars-d :
>
>> On 1 May 2017 at 14:40, Iain Buclaw  wrote:
>> > So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)
>>
>> With the latter also testing all crosses we can do (there are 18
>> different gdc cross-compilers in Ubuntu, for 12 distinct
>> architectures).
>
> BTW is there some documentation on how to update / rebuild these
> debian / ubuntu packages with updated GDC sources?
>
> -- Johannes
>

Doubt it, the debian source packages are quite complex too - though
there's only a few places that need changing, once you work out
exactly *where*.

As you're just updating GDC sources, it should just be a case of
replacing the gdc tarball with a new copy, and the rest is already
handled.

Re: DIP 1004 Preliminary Review Round 1

[Andrej Mitrovic via Digitalmars-d]

On Monday, 1 May 2017 at 15:33:47 UTC, Basile B. wrote:

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:

DIP 1004 is titled "Inherited Constructors. [...]
All review-related feedback on and discussion of the DIP 
should occur in this thread. [...]

Destroy!


An obvious omission in the syntax variations [1]

- alias this() = super.this();

or

- alias this = super.this;


I thought people would catch on that this is implied. :) The 
old-style or new-style alias syntax should both be allowed, in my 
opinion. The main issue is what to do about the parentheses, 
whether to include them or not.

Re: Porting Java code to D that uses << and >>> operators

[bachmeier via Digitalmars-d-learn]

On Monday, 1 May 2017 at 15:53:41 UTC, Basile B. wrote:

It's the same code in D. It extracts consecutive bits in x12 
and x13 (and maskxx), put them at the beginning (right shift) 
and add them.


Thanks.

Re: Porting Java code to D that uses << and >>> operators

[Basile B. via Digitalmars-d-learn]

On Monday, 1 May 2017 at 15:45:00 UTC, bachmeier wrote:
I'm porting a small piece of Java code into D, but I've run 
into this:


int y1 = ((x12 & MASK12) << 22) + (x12 >>> 9) + ((x13 & MASK13) 
<< 7) + (x13 >>> 24);


I have a basic understanding of those operators in both 
languages, but I can't find a sufficiently detailed explanation 
to tell me how to translate the Java into D and know that it's 
guaranteed to give the same result. Can someone tell me the 
correct D code to use?


It's the same code in D. It extracts consecutive bits in x12 and 
x13 (and maskxx), put them at the beginning (right shift) and add 
them.

Re: What are we going to do about mobile?

[Johannes Pfau via Digitalmars-d]

Am Mon, 1 May 2017 14:44:35 +0200
schrieb Iain Buclaw via Digitalmars-d :

> On 1 May 2017 at 14:40, Iain Buclaw  wrote:
> > So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)  
> 
> With the latter also testing all crosses we can do (there are 18
> different gdc cross-compilers in Ubuntu, for 12 distinct
> architectures).

BTW is there some documentation on how to update / rebuild these
debian / ubuntu packages with updated GDC sources? 

-- Johannes

Porting Java code to D that uses << and >>> operators

[bachmeier via Digitalmars-d-learn]

I'm porting a small piece of Java code into D, but I've run into 
this:


int y1 = ((x12 & MASK12) << 22) + (x12 >>> 9) + ((x13 & MASK13) 
<< 7) + (x13 >>> 24);


I have a basic understanding of those operators in both 
languages, but I can't find a sufficiently detailed explanation 
to tell me how to translate the Java into D and know that it's 
guaranteed to give the same result. Can someone tell me the 
correct D code to use?

Re: Using the same name for diffrent entities

[Basile B. via Digitalmars-d-learn]

On Monday, 1 May 2017 at 14:01:19 UTC, Noy wrote:

Hello,
Is it possible to use the same name for different entities? For 
example calling a variable and a class\function by the same 
name.


It only works with functions that take different parameters or 
with templated functions that have constraints, aka "overloads", 
because the compiler can determine what you want to call.

Re: DIP 1004 Preliminary Review Round 1

[Basile B. via Digitalmars-d]

On Monday, 1 May 2017 at 15:33:47 UTC, Basile B. wrote:

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:

DIP 1004 is titled "Inherited Constructors. [...]
All review-related feedback on and discussion of the DIP 
should occur in this thread. [...]

Destroy!


An obvious omission in the syntax variations [1]

- alias this() = super.this();

or

- alias this = super.this;



or even

alias this() = Base.this()

with Base the identifier for the base class, which is already the 
syntax for virtual methods ;)

Re: DConf Hackathon Ideas

[bachmeier via Digitalmars-d]

On Monday, 1 May 2017 at 14:51:19 UTC, Mike Parker wrote:

I love SDL and much prefer it over JSON for DUB configs. Use it 
for all of my D projects. It looks cleaner and supports 
comments. I really would hate to see support dropped.


I'm not even sure what it would mean to "drop" support for SDL. 
As long as someone decides to support it, it will be supported. 
SDL to my knowledge is not an "official" D project.

Re: DIP 1004 Preliminary Review Round 1

[Basile B. via Digitalmars-d]

On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:

DIP 1004 is titled "Inherited Constructors. [...]
All review-related feedback on and discussion of the DIP should 
occur in this thread. [...]

Destroy!


An obvious omission in the syntax variations [1]

- alias this() = super.this();

or

- alias this = super.this;


Why ?

1/ AliasDeclarationY [2] is the most modern and most used alias 
syntax nowadays.
2/ it's less confusing with the "alias this" that's used for 
static inheritance.


[1] 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md#syntax-variations

[2] https://dlang.org/spec/declaration.html#AliasDeclarationY

Re: Using the same name for diffrent entities

[Mike Parker via Digitalmars-d-learn]

On Monday, 1 May 2017 at 14:01:19 UTC, Noy wrote:

Hello,
Is it possible to use the same name for different entities? For 
example calling a variable and a class\function by the same 
name.


Symbols declared in the same scope must be unique. For example:

```
module foo;

int bar;
void bar();
class bar {}
```

This will not compile as the three symbols conflict. But:

```
module foo1;
int bar;

module foo2;
void bar();

module foo3;
import foo1, foo2;

class bar {}
```
This is fine. You can disambiguate using fully qualified names: 
`bar` will refer to the class, foo1.bar to the variable, and 
foo2.bar to the function.


You can shadow symbols in inner scopes:

```
class bar {}

void main() {
void bar() {}
void foo() { int bar; }
}
```
That would be really confusing, though.

Re: DConf Hackathon Ideas

[Andre Pany via Digitalmars-d]

On Thursday, 27 April 2017 at 22:57:48 UTC, Moritz Maxeiner wrote:

On Thursday, 27 April 2017 at 19:55:44 UTC, Andre Pany wrote:
On Thursday, 27 April 2017 at 17:47:19 UTC, Moritz Maxeiner 
wrote:

[...]


As workaround this is possible. Every developer and in every 
continious integration build step, dub is used, you have to 
remember to use these arguments. Defining it one time in 
dub.json would be great.


Alright, I take your point. Since the internal functionality 
itself is already there, this seems like an easy fix (just add 
a new field to the json/sdlang parsing of dub and bind it to 
what the CLI arguments already do). Have you opened a dub issue 
about this (first step to getting an issue fixed and so on), I 
wasn't able to find one on first glance?


I created an issue in the dub github repository
https://github.com/dlang/dub/issues/1119

Kind regards
André

DIP 1004 Preliminary Review Round 1 Begins

[Mike Parker via Digitalmars-d-announce]

The first preliminary review of DIP 1004, "Inherited 
Constructors" has begun.


http://forum.dlang.org/post/bsasudihqubudwgpr...@forum.dlang.org

Don't forget that the review of DIP 1005 ends on May 13.

http://forum.dlang.org/thread/ckqhwodtjgpcqklcy...@forum.dlang.org

Also, the review of DIP 1007 ends on May 15.

http://forum.dlang.org/post/hjdstwzhcbrektlij...@forum.dlang.org

DIP 1004 Preliminary Review Round 1

[Mike Parker via Digitalmars-d]

DIP 1004 is titled "Inherited Constructors.

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md

All review-related feedback on and discussion of the DIP should 
occur in this thread. Due to DConf taking place during the review 
period, the period will be extended by a week. The review period 
will end at 11:59 PM ET on May 22 (3:59 AM GMT May 23), or when I 
make a post declaring it complete.


At the end of Round 1, if further review is deemed necessary, the 
DIP will be scheduled for another round. Otherwise, it will be 
queued for the formal review and evaluation by the language 
authors.


Thanks in advance to all who participate.

Destroy!

Re: DConf Hackathon Ideas

[Mike Parker via Digitalmars-d]

On Monday, 1 May 2017 at 14:38:11 UTC, Joseph Rushton Wakeling 
wrote:

On Thursday, 27 April 2017 at 16:33:02 UTC, singingbush wrote:

SDL should be dropped.


Deprecated, sure.  But dropping it seems a bad idea given that 
various projects do still use it for their DUB package config.



NOBODY USES IT!


Probably not true.  Perhaps a hackathon project could be to 
create a little app to find which projects on GitHub (or at 
least code.dlang.org) still use a `dub.sdl`, and auto-submit a 
PR to fix that? :-)


I love SDL and much prefer it over JSON for DUB configs. Use it 
for all of my D projects. It looks cleaner and supports comments. 
I really would hate to see support dropped.

Re: DConf Hackathon Ideas

[Joseph Rushton Wakeling via Digitalmars-d]

On Thursday, 27 April 2017 at 16:33:02 UTC, singingbush wrote:

SDL should be dropped.


Deprecated, sure.  But dropping it seems a bad idea given that 
various projects do still use it for their DUB package config.



NOBODY USES IT!


Probably not true.  Perhaps a hackathon project could be to 
create a little app to find which projects on GitHub (or at least 
code.dlang.org) still use a `dub.sdl`, and auto-submit a PR to 
fix that? :-)

Re: [OT] Algorithm question

[Ivan Kazmenko via Digitalmars-d]

On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
Given a set A of n elements (let's say it's a random-access 
range of

size n, where n is relatively large), and a predicate P(x) that
specifies some subset of A of elements that we're interested 
in, what's
the best algorithm (in terms of big-O time complexity) for 
selecting a
random element x satisfying P(x), such that elements that 
satisfy P(x)
have equal probability of being chosen? (Elements that do not 
satisfy

P(x) are disregarded.)


I'd like to note here that, if you make use of the same P(x) many 
times (instead of different predicates on each call), it makes 
sense to spend O(n) time and memory filtering by that predicate 
and storing the result, and then answer each query in O(1).



3) Permutation walk:

auto r = ... /* elements of A */
foreach (i; iota(0 .. r.length).randomPermutation) {
if (P(r[i])) return r[i];
}
/* no elements satisfy P(x) */

   Advantages: if an element that satisfies P(x) is found 
early, the
   loop will terminate before n iterations. This seems like the 
best of

   both worlds of (1) and (2), except:

   Disadvantages: AFAIK, generating a random permutation of 
indices from
   0 .. n requires at least O(n) time, so any advantage we may 
have had

   seems to be negated.

Is there an algorithm for *incrementally* generating a random 
permutation of indices? If there is, we could use that in (3) 
and thus achieve the best of both worlds between early 
termination if an element satisfying P(x) is found, and 
guaranteeing termination after n iterations if no elements 
satisfying P(x) exists.


Yes, there is.

There are actually two variations of Fisher-Yates shuffle:
(https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle)

1.
auto p = n.iota.array;
foreach (pos; 0..n) {
auto otherPos = uniform (0, pos + 1);
swap (p[pos], p[otherPos]);
}

When we look at this after k-th iteration, the first k elements 
are randomly and uniformly permuted, and the rest (n-k) are left 
untouched.


2.
auto p = n.iota.array;
foreach (pos; 0..n) {
auto otherPos = uniform (pos, n);
swap (p[pos], p[otherPos]);
}

When we look at this after k-th iteration, the first k elements 
are a random combination of all n elements, and this combination 
is randomly and uniformly permuted.  So, the second variation is 
what we need: each new element is randomly and uniformly selected 
from all the elements left.  Once we get the first element 
satisfying the predicate, we can just terminate the loop.  If 
there are m out of n elements satisfying the predicate, the 
average number of steps is n/m.


Now, the problem is that both of these allocate n "size_t"-s of 
memory to start with.  And your problem does not allow to shuffle 
the elements of the original array in place, so we do need an 
external permutation for these algorithms.  However, there are at 
least two ways to mitigate that:


(I)
We can allocate the permutation once using n time and memory, and 
then, on every call, just reuse it in its current state in n/m 
time.  It does not matter if the permutation is not identity 
permutation: by symmetry argument, any starting permutation will 
do just fine.


(II)
We can store the permutation p in an associative array instead of 
a regular array, actually storing only the elements accessed at 
least once, and assuming other elements to satisfy the identity 
p[x] = x.  So, if we finish in n/m steps on average, the time and 
extra memory used will be O(n/m) too.  I can put together an 
example implementation if this best satisfies your requirements.


Ivan Kazmenko.

Snap packages for LDC 1.2.0

[Joseph Rushton Wakeling via Digitalmars-d-announce]

Hello all :-)

Stable snap packages for LDC 1.2.0 have been available since 
before the official 1.2.0 release announcement 1 week ago.  
However, since there's more than just the availability of the 
packages to announce, I thought I'd write up some notes for the 
forums.


The full writeup (including installation instructions) is 
available here:

https://forum.dlang.org/post/tqxfcvdzcqendwyyd...@forum.dlang.org

but in short, the latest news can be summarized as:

  * the packaged LDC version has been updated to 1.2.0, comprising
DMD/druntime/phobos 2.072.2 and LLVM 4.0

  * packages are now available for both i386 and amd64 
architectures,

with ongoing work to extend the list

  * specific release tracks are now available, allowing users to
install and update from either the latest LDC releases or from
specific minor release series

  * these packages are expected to work with (at least) Ubuntu 
14.04,
16.04, 16.10, 17.04 and development releases; Debian Testing 
and

Unstable; and OpenSUSE Leap.

Please report any issues encountered with the packages here:
https://github.com/ldc-developers/ldc2.snap.

Enjoy, and please do let me know how you get on with using these 
packages!


Thanks & best wishes,

-- Joe

Using the same name for diffrent entities

[Noy via Digitalmars-d-learn]

Hello,
Is it possible to use the same name for different entities? For 
example calling a variable and a class\function by the same name.

[Issue 17361] latest windows 10 insider preview and dmd no longer runs.

[via Digitalmars-d-bugs]

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

--- Comment #1 from steven kladitis  ---
I have noticed that the replace.exe is also a windows command. They do not
behave the same.
I can try anything anybody suggests to help solve the mystery.

This does Include removing WinDoze. :):):)

Thanks,
Steven

--

Re: parallel foreach

[Nicholas Wilson via Digitalmars-d-learn]

On Monday, 1 May 2017 at 12:42:01 UTC, Alex wrote:

Hi all,
the last foreach in the following code does not compile... Is 
this a bug, or is something wrong with my syntax?


void main()
{
import std.parallelism : parallel;
import std.range : iota;

foreach(i; iota(0, 5)){}
foreach(i; staticIota!(0, 5)){}
foreach(i; parallel(iota(0, 5))){}
foreach(i; parallel(staticIota!(0, 5))){}
}

// copied from core.internal.traits
template staticIota(int beg, int end)
{
import std.typetuple;
static if (beg + 1 >= end)
{
static if (beg >= end)
{
alias staticIota = TypeTuple!();
}
else
{
alias staticIota = TypeTuple!(+beg);
}
}
else
{
enum mid = beg + (end - beg) / 2;
alias staticIota = TypeTuple!(staticIota!(beg, mid), 
staticIota!(mid, end));

}
}


Because staticIota expands to 0,1,2,3,4
so you are trying todo
foreach(i; parallel(0,1,2,3,4){}
which doesn't work.
try
foreach(i; parallel([staticIota!(0, 5)])){}
or
foreach(i; parallel(only(staticIota!(0, 5{}
not sure of the second one will work.

Re: OT: Re: DConf Hackathon Ideas

[Nicholas Wilson via Digitalmars-d]

On Monday, 1 May 2017 at 12:35:11 UTC, Petar Kirov [ZombineDev] 
wrote:
On Saturday, 29 April 2017 at 00:54:59 UTC, Nicholas Wilson 
wrote:
On Friday, 28 April 2017 at 13:31:33 UTC, Petar Kirov 
[ZombineDev] wrote:

Other applications include:
* compiling/transpiling D functions to targets
like JS, SPIR-V,


I got you covered ;)


I know, and I'm looking forward to using your GPU support in 
LDC :P


(LDC not CTFE though. It would be fiendishly complicated to do 
at CTFE as a fair amount of compiler magic is necessary.)


The way I see it, metaprogramming is a whole spectrum. Yes, you
need a full compiler if you want to compile a whole program to
e.g. JS or WebAsm, but there are many areas where even the 
smallest

improvement would be highly beneficial.



Oh I agree. For text to text (or lambda to text) this is 
comprehensible and not too difficult (perhaps even simple with 
Dmitry Olshansky's Pry) but SPIRV is rather complicated, as 
evidenced by a 203 page spec *(that doesn't even include the 
OpenCL or Vulkan specific stuff). Having said that it shouldn't 
be too difficult to port the tablegen tables I've been working on 
for LLVM to D (or write a D backend for tablegen) and get most of 
the really boring work out of the way.
I won't stop you, but just letting you know the rabbit hole is 
quite deep :)


The good news is the the runtime stuff will be all transferable.
This approach for SPIRV won't automatically translate for NVPTX 
like it will for ldc though, which is one of the main draws for 
dcompute


*Other languages probably have longer specs, but this is just for 
the format.



Take for example C#. It has zero CTFE capabilities (you can
safely ignore constant folding, which works only with string 
and number literals),
yet it has pretty powerful reflection and code-generation 
capabilities
at run-time. Even though the performance difference between CT 
and RT
reflection is orders of magnitude, those reflection 
capabilities are used
pervasively throughout the whole ecosystem. The prime example 
being LINQ -
probably the most widely used feature of .NET. Given a chain of 
operations

(similar to D's ranges) like:

dbContext.Persons
  .Where(p => p.Birthdate < DateTime.Now.Date.AddYears(-18))
  .Where(p => p.Birthdate > DateTime.Now.Date.AddYears(-28))
  .Select(p => new { Name = p.FirstName + " " + p.LastName, 
Birthdate = p.Birthdate })


It gets compiled to the following SQL:
-- Region Parameters
DECLARE @p0 DateTime = '1989-05-01 00:00:00.000'
DECLARE @p1 DateTime = '1999-05-01 00:00:00.000'
DECLARE @p2 NVarChar(1000) = ' '
-- EndRegion
SELECT ([t0].[FirstName] + @p2) + [t0].[LastName] AS [Name], 
[t0].[Birthdate]

FROM [Person] AS [t0]
WHERE ([t0].[Birthdate] > @p0) AND ([t0].[Birthdate] < @p1)

As you can see the mapping and filtering is done entirely on the
database server side. The only magic need is to make the 
compiler to

dump the AST. In C# that's accomplished by wrapping the function
type F in to an Expression [0]. For example C#'s analog of:

InputRange!T filter(T)(InputRange!T source, bool delegate(T) 
predicate)


is expressed as:

IEnumerable Where(IEnumerable source, Func 
predicate)


In order to request the AST of the predicate function, it needs 
to

be wrapped in Expression:

IQueryable Where(
IQueryable source, Expression> predicate)

(IQueryable [1] is an extension of IEnumerable [2] 
interface (which is
similar to D's Input/ForwardRange-s) which adds the Expression 
property
which represents the AST of the query against the IQueryable 
data source.)




In addition to compiling range operations to database queries, 
this would
also be useful specializing on lambda's in range libraries (see 
[3]) and

much more.


[0]: 
https://msdn.microsoft.com/en-us/library/bb335710(v=vs.110).aspx
[1]: 
https://msdn.microsoft.com/en-us/library/bb351562(v=vs.110).aspx
[2]: 
https://msdn.microsoft.com/en-us/library/9eekhta0(v=vs.110).aspx

[3]: https://github.com/dlang/phobos/pull/4265

Re: DConf Hackathon Ideas

[Steven Schveighoffer via Digitalmars-d]

On 4/29/17 5:42 AM, Daniel N wrote:

On Thursday, 27 April 2017 at 14:53:02 UTC, Mike Parker wrote:

This year, DConf has an extra day tacked on for problem solving in the
form of a hackathon. The intent is to work on issues people find
frustrating in the D ecosystem. While there will be time given at the
event for proposals, and those involving third-party projects are
welcome, it will help speed things along for the organizers to come in
with a list of big issues to get the ball rolling.

To help in compiling the list, what are some major issues from the
ecosystem that you'd like to see fixed?


Wishlist
1) Make alias parameters work with buildin types, I bet anyone using D
has fallen into trip trap.

alias X(alias T) = T;
X!int x;



+1, I would love to see this fixed. I recall Walter said it should be 
fixed 2 years ago in Utah.


-Steve

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Andrei Alexandrescu via Digitalmars-d]

On 05/01/2017 08:12 AM, Guillaume Piolat wrote:

On Sunday, 30 April 2017 at 21:43:26 UTC, Andrei Alexandrescu wrote:


A pass through the root allocators (Mallocator, GCAllocator etc)
figuring out what attributes could be meaningfully attached would be
welcome. The rest would rely on inference.


Thanks,

Andrei


IAllocator being fully @nogc would be a comforting guarantee, as runtime
dispatch makes for lighter types.


As I said (and am encouraging you to do this), this is achieved through 
simple variance:


interface INoGCAllocator : IAllocator {
   ... override all methods here as @nogc ...
}

This is possible because a @nogc method may override one that is not 
@nogc. @nogc being more restrictive it is contravariant with no-@nogc.


Also IAllocator should have a few @nogc methods to start with; there's 
no reason e.g. for empty() to create garbage.


Could you please initiate a PR?


Andrei

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 12:38:32 UTC, Andrea Fontana wrote:

On Monday, 1 May 2017 at 12:31:48 UTC, Andrea Fontana wrote:
If you find an element that doesn't satisfy P(x) move it on 
top of array (swap!) and then try again with uniform(1, 
r.length - 1) and so on.



Whoops i mean uniform(1, r.length) of course :)


I guess you meant to the end, but if mutating the array is ok, 
then you don't have to swap. Just move in the last element and 
chop 1 off the length.


Another cache-friendly mutation solution (assuming PRNG is cheap) 
is to have two phases:


Phase 1:
linear walkover the array and select elements with P(a[i])==true 
with probability 1/N

the overwrite the ones with P(a[i]) = false.

when done truncate the array.

Phase 2:
regular random selection from the array were all elements satisfy 
P.


The OP underspecified the requirements... There is a gazillion 
variations... :-P

Re: alias this on module

[Steven Schveighoffer via Digitalmars-d]

On 4/30/17 7:59 PM, Jonathan Marler wrote:

On Sunday, 30 April 2017 at 23:44:32 UTC, Steven Schveighoffer wrote:

On 4/30/17 7:35 PM, Jonathan Marler wrote:

Any reason why "alias this" doesn't work at the module level?  If I
recall correctly, a module is really just a "class" under the hood, but
when I tried to use it I got:

Error: alias this can only be a member of aggregate, not module




public import is to modules as alias this is to structs/classes :)



They're actually different.

//
// File: mymodule.d
//
module mymodule;

struct Foo
{
int bar;
void baz();
}
__gshared Foo foo;
alias foo this; // using "alias this" on a module


So you want to alias a struct to a module? That's different than what I 
thought, I thought you wanted to alias one module's members into another.


I can't see a reason why it couldn't be added as a feature. I admit I'm 
not seeing the benefit though.


You could simulate this via a mixin. e.g.:

void baz()
{
   foo.baz;
}

@property ref bar()
{
   return foo.bar;
}

-Steve

parallel foreach

[Alex via Digitalmars-d-learn]

Hi all,
the last foreach in the following code does not compile... Is 
this a bug, or is something wrong with my syntax?


void main()
{
import std.parallelism : parallel;
import std.range : iota;

foreach(i; iota(0, 5)){}
foreach(i; staticIota!(0, 5)){}
foreach(i; parallel(iota(0, 5))){}
foreach(i; parallel(staticIota!(0, 5))){}
}

// copied from core.internal.traits
template staticIota(int beg, int end)
{
import std.typetuple;
static if (beg + 1 >= end)
{
static if (beg >= end)
{
alias staticIota = TypeTuple!();
}
else
{
alias staticIota = TypeTuple!(+beg);
}
}
else
{
enum mid = beg + (end - beg) / 2;
alias staticIota = TypeTuple!(staticIota!(beg, mid), 
staticIota!(mid, end));

}
}

Re: What are we going to do about mobile?

[Iain Buclaw via Digitalmars-d]

On 1 May 2017 at 14:40, Iain Buclaw  wrote:
> So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)

With the latter also testing all crosses we can do (there are 18
different gdc cross-compilers in Ubuntu, for 12 distinct
architectures).

Re: What are we going to do about mobile?

[Iain Buclaw via Digitalmars-d]

On 16 April 2017 at 11:54, Iain Buclaw  wrote:
> On 16 April 2017 at 11:20, Johannes Pfau via Digitalmars-d
>  wrote:
>> Am Sun, 16 Apr 2017 10:13:50 +0200
>> schrieb Iain Buclaw via Digitalmars-d :
>>
>>>
>>> I asked at a recent D meetup about what gitlab CI used as their
>>> backing platform, and it seems like it's a front for TravisCI.  YMMV,
>>> but I found the Travis platform to be too slow (it was struggling to
>>> even build GDC in under 40 minutes), and too limiting to be used as a
>>> CI for large projects.
>>
>> That's probably for the hosted gitlab solution though. For self-hosted
>> gitlab you can set up custom machines as gitlab workers. The biggest
>> drawback here is missing gitlab integration.
>>
>>>
>>> Johannes, what if I get a couple new small boxes, one ARM, one
>>> non-descriptive x86.  The project site and binary downloads could then
>>> be used to the non-descriptive box, meanwhile the ARM box and the
>>> existing server can be turned into a build servers - there's enough
>>> disk space and memory on the current server to have a at least half a
>>> dozen build environments on the current server, testing also i386 and
>>> x32 would be beneficial along with any number cross-compilers
>>> (testsuite can be ran with runnable tests disabled).
>>
>> Sounds like a plan. What CI server should we use though?
>>
>
> I was thinking of keeping it simple, buildbot maybe?
>
> http://buildbot.net/


I provisionally got an account with these guys last month, and now
I've just seen this:

https://blog.online.net/2017/04/27/scaleway-disruptive-armv8-cloud-servers/

So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)

Re: [OT] Algorithm question

[Andrea Fontana via Digitalmars-d]

On Monday, 1 May 2017 at 12:31:48 UTC, Andrea Fontana wrote:
If you find an element that doesn't satisfy P(x) move it on top 
of array (swap!) and then try again with uniform(1, r.length - 
1) and so on.



Whoops i mean uniform(1, r.length) of course :)

Re: OT: Re: DConf Hackathon Ideas

[via Digitalmars-d]

On Saturday, 29 April 2017 at 00:54:59 UTC, Nicholas Wilson wrote:
On Friday, 28 April 2017 at 13:31:33 UTC, Petar Kirov 
[ZombineDev] wrote:

Other applications include:
* compiling/transpiling D functions to targets
like JS, SPIR-V,


I got you covered ;)


I know, and I'm looking forward to using your GPU support in LDC 
:P


(LDC not CTFE though. It would be fiendishly complicated to do 
at CTFE as a fair amount of compiler magic is necessary.)


The way I see it, metaprogramming is a whole spectrum. Yes, you
need a full compiler if you want to compile a whole program to
e.g. JS or WebAsm, but there are many areas where even the 
smallest

improvement would be highly beneficial.

Take for example C#. It has zero CTFE capabilities (you can
safely ignore constant folding, which works only with string and 
number literals),
yet it has pretty powerful reflection and code-generation 
capabilities
at run-time. Even though the performance difference between CT 
and RT
reflection is orders of magnitude, those reflection capabilities 
are used
pervasively throughout the whole ecosystem. The prime example 
being LINQ -
probably the most widely used feature of .NET. Given a chain of 
operations

(similar to D's ranges) like:

dbContext.Persons
  .Where(p => p.Birthdate < DateTime.Now.Date.AddYears(-18))
  .Where(p => p.Birthdate > DateTime.Now.Date.AddYears(-28))
  .Select(p => new { Name = p.FirstName + " " + p.LastName, 
Birthdate = p.Birthdate })


It gets compiled to the following SQL:
-- Region Parameters
DECLARE @p0 DateTime = '1989-05-01 00:00:00.000'
DECLARE @p1 DateTime = '1999-05-01 00:00:00.000'
DECLARE @p2 NVarChar(1000) = ' '
-- EndRegion
SELECT ([t0].[FirstName] + @p2) + [t0].[LastName] AS [Name], 
[t0].[Birthdate]

FROM [Person] AS [t0]
WHERE ([t0].[Birthdate] > @p0) AND ([t0].[Birthdate] < @p1)

As you can see the mapping and filtering is done entirely on the
database server side. The only magic need is to make the compiler 
to

dump the AST. In C# that's accomplished by wrapping the function
type F in to an Expression [0]. For example C#'s analog of:

InputRange!T filter(T)(InputRange!T source, bool delegate(T) 
predicate)


is expressed as:

IEnumerable Where(IEnumerable source, Func 
predicate)


In order to request the AST of the predicate function, it needs to
be wrapped in Expression:

IQueryable Where(
IQueryable source, Expression> predicate)

(IQueryable [1] is an extension of IEnumerable [2] 
interface (which is
similar to D's Input/ForwardRange-s) which adds the Expression 
property
which represents the AST of the query against the IQueryable data 
source.)




In addition to compiling range operations to database queries, 
this would
also be useful specializing on lambda's in range libraries (see 
[3]) and

much more.


[0]: 
https://msdn.microsoft.com/en-us/library/bb335710(v=vs.110).aspx
[1]: 
https://msdn.microsoft.com/en-us/library/bb351562(v=vs.110).aspx
[2]: 
https://msdn.microsoft.com/en-us/library/9eekhta0(v=vs.110).aspx

[3]: https://github.com/dlang/phobos/pull/4265

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 11:57:32 UTC, Ola Fosheim Grøstad wrote:

Ah, found a sensible search term: «pseudorandom permutation»

http://cse.iitkgp.ac.in/~debdeep/courses_iitkgp/FCrypto/slides/LubyRackoff.pdf

If you go down this path, please share links. Useful stuff 
actually.


A readable paper for most people:
http://www.pcg-random.org/pdf/toms-oneill-pcg-family-v1.02.pdf

«some users would prefer a much stronger property analogous to
uniformity: that over the full period of the generator, every 
possible k-tuple will occur,

and it will occur the same number of times.»

PCG claims to have arbitrary cycle sizes.

I haven't looked at it, but it is available as C/C++.

Re: [OT] Algorithm question

[Andrea Fontana via Digitalmars-d]

On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:

1) "Random shooting":

auto r = ... /* elements of A */
for (;;) {
auto i = uniform(0, r.length);
if (P(r[i])) return r[i];
}

   Advantages: If a large percentage of elements in A satisfy 
P(x), then
   the loop will terminate within a small number of iterations; 
if the
   majority of elements satisfy P(x), this will terminate well 
below n

   iterations.

   Disadvantages: If only a small percentage of elements 
satisfy P(x),
   then this loop could take arbitrarily long to terminate, and 
it will

   not terminate at all if no elements satisfy P(x).



If you find an element that doesn't satisfy P(x) move it on top 
of array (swap!) and then try again with uniform(1, r.length - 1) 
and so on.


It terminates in this way.

Andrea

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Guillaume Piolat via Digitalmars-d]

On Sunday, 30 April 2017 at 21:43:26 UTC, Andrei Alexandrescu 
wrote:


A pass through the root allocators (Mallocator, GCAllocator 
etc) figuring out what attributes could be meaningfully 
attached would be welcome. The rest would rely on inference.



Thanks,

Andrei


IAllocator being fully @nogc would be a comforting guarantee, as 
runtime dispatch makes for lighter types.

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

Ah, found a sensible search term: «pseudorandom permutation»

http://cse.iitkgp.ac.in/~debdeep/courses_iitkgp/FCrypto/slides/LubyRackoff.pdf

If you go down this path, please share links. Useful stuff 
actually.

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 11:15:28 UTC, Ola Fosheim Grøstad wrote:
But permutations is the way to go if you want scientific 
quality.


I take that back:

«Polynomial pseudo-random number generator via cyclic phase»
http://www.sciencedirect.com/science/article/pii/S0378475409001463

Might be what you are looking for and if not it probably 
references other papers that fits the bill.

Re: [OT] Algorithm question

[Mike B Johnson via Digitalmars-d]

On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
I'm been thinking about the following problem, and thought I'd 
pick the brains of the bright people around these parts...


[...]



Since most real world problems would require selecting elements 
more than once it may be far more efficient to sort by 
P(x)(filter) then simply select a random element.


e.g.,

a = A.filter(x->P(x))  // Creates a new set a where only the 
elements of A that satisfy P(x) are added


...

e = a.random;


this is O(1) if you only have to filter once(you can create a 
container that always "sorts" on P(x) so to speak.. like a sorted 
dictionary).

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 11:08:56 UTC, Ola Fosheim Grøstad wrote:
E.g. find a set of cyclic random generators and break down N 
into a sum of these cycle-sizes, then just keep track of the 
seed for each. If they are 2^N then you could use xor to get 
more randomness between runs.


Also in the algorithms above you need to change the 
probabilities each time you take away one index from a group 
(you don't want to draw from an empty group).


Well, actually, just select the single cyclic generator that is 
larger or equal to N, then just redraw if it returns a value >= 
N. Duh! Sloppy thinking. I would think you should be able to find 
some prime sized ones that will get the next index with an 
insignificant number of redraws.


But permutations is the way to go if you want scientific quality.

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 10:51:46 UTC, Ola Fosheim Grøstad wrote:
Keep also in mind that you can split the original array in two, 
so it might be sufficient to  have the permutations for various 
2^M sizes if those are easier to generate (my guess, maybe 
through some xor magic?)


E.g. if N = 21 then it can be split into 16 + (4 + 1)

So you can draw like this:

1. randomly select group_16 over group_5 based with 16/21 
probability)


2. if group_5 selected: ramdomly select group_4 over group 1 on 
4/5 probability


etc.

That way you only need log(N) permutation sequences to keep 
track of. Which for all practical purposes are going to stay 
pretty low (<20?)


Right?



But if you don't use a hardware random generator and are happy 
with more sloppy pseudo-randomness then you would be better of 
ditching the whole concept of permutations and replace it with 
some cylic random generators intead using the same technique I 
just outlined.


E.g. find a set of cyclic random generators and break down N into 
a sum of these cycle-sizes, then just keep track of the seed for 
each. If they are 2^N then you could use xor to get more 
randomness between runs.


Also in the algorithms above you need to change the probabilities 
each time you take away one index from a group (you don't want to 
draw from an empty group).

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 08:44:25 UTC, Ola Fosheim Grøstad wrote:
Does it exist? Yes, because you can build permutation tables 
for it, but you'll have to find the closed form for it that is 
efficient... Can you do that without selecting a specific N? It 
is easy for N=2 and N=3 at least.


E.g.

For array length 2 you get the 2 permutations: 0 1, 1 0
Then you just select one of them at random (you know the number 
of permutations)


So if it exists you'll should probably do a search for 
permutations. "How do I efficiently generate permutation number 
N"


Of course for smaller N you could generate a big array of bytes 
and compress it by having arrays of slices into it (as many 
permutations will share index sequences).


Keep also in mind that you can split the original array in two, 
so it might be sufficient to  have the permutations for various 
2^M sizes if those are easier to generate (my guess, maybe 
through some xor magic?)


E.g. if N = 21 then it can be split into 16 + (4 + 1)

So you can draw like this:

1. randomly select group_16 over group_5 based with 16/21 
probability)


2. if group_5 selected: ramdomly select group_4 over group 1 on 
4/5 probability


etc.

That way you only need log(N) permutation sequences to keep track 
of. Which for all practical purposes are going to stay pretty low 
(<20?)


Right?

[Issue 17162] std.algorithm.startsWith fails to compile with -dip1000 switch

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

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

--

[Issue 17304] [SPEC] Anonymous symbols, show or ignore in demangler?

[via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Buclaw  ---
This has been committed into gcc.

https://gcc.gnu.org/viewcvs/gcc?view=revision=247434

--

Re: It's alive! D building D building D, all on Android

[rikki cattermole via Digitalmars-d-announce]

On 01/05/2017 11:31 AM, Joakim wrote:

On Monday, 27 February 2017 at 17:08:26 UTC, Joakim wrote:

On Thursday, 29 December 2016 at 09:16:58 UTC, Joakim wrote:

On Sunday, 15 May 2016 at 11:09:01 UTC, Joakim wrote:

On Wednesday, 11 May 2016 at 19:07:10 UTC, Joakim wrote:

[...]


I've put up three more builds, including ldc master, which uses the
latest 2.071 frontend.  Once I get JNI and the sample app working,
I'll make a proper announcement.


I've put up the latest native and cross-compiler ldc 1.1.0 beta
builds for Android, fresh from the master branch and using the 2.071
frontend:

https://github.com/joakim-noah/android/releases

I believe I've fixed the issue that was causing random crashes in the
sample apps, a regression from porting the NDK's C wrapper to D,
found by Vadim Lopatim.  I've added three sample apps that
demonstrate calling D code from JNI.

The sample C++ Teapot app from the NDK has been ported to D and
mostly works, including calling Java methods from D through JNI, but
I need to track down some other touch-related bugs from the port
before committing it.  I'm finishing up reggae files to make building
the sample apps very easy.  I'd like to write up the process to build
and use ldc natively on your Android mobile device, from the Termux
app, on the wiki.

Once those three are done, I'll create a new thread to properly
announce this beta; in the meantime, nothing will change with these
new beta builds, so try them out.


Piping hot builds of the upcoming ldc 1.1.1 release available as both
a linux/x64 -> Android/ARM cross-compiler and a native Android/ARM
compiler, that you can run on your own phone or tablet:

https://github.com/joakim-noah/android/releases

I finally spent some time tracking down that touch bug in the sample
Teapot app, think I know where it's coming from now, just need to fix it.


Based on the recent 1.2 release of ldc, new builds for Android are up:

https://github.com/joakim-noah/android/releases

Notice how small the patches for ldc are, now that kinke added support
for cross-compiling reals to lower-precision platforms, basically just a
few additions to the CMake script to cross-compile the standard library
left.  Only a single assert from the stdlib tests trips, a longtime
codegen issue in std.random that became visible now, and the entire
compiler dmd-testsuite passes.

I'll update the wiki, upload my remaining patches, post upstream PRs,
and finally clean up and put out that sample Teapot app, which shows
using JNI to call Java functions from your D app, this week.


Yay!

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 09:01:33 UTC, Ola Fosheim Grøstad wrote:
array of indexes and mutate that instead, still O(N). If you 
cache in a heap you get O(N log N).


To avoid confusion: I didn't mean a literal "heap", but some kind 
of search structure that tracks and draws from unused indice 
ranges in a way that does not require O(N) initialization and can 
be implemented as a single array on the stack. I don't remember 
what it is called, but you draw on each node based on the number 
of children (kind of like the ones used in markov-chain type 
situations). I assume this can be maintained in O(log N) per 
iteration with O(1) initialization.


E.g.

1. push_indices(0,N-1) //data (0,N-1)
2. i = draw_and_remove_random_index() // data could now be 
(0,i-1), (i+1,N-1)

3. if( i == -1 ) return
4. dostuff(i)
5. goto 2


Even though it is O(N log N) it could outperform other solutions 
if you only want to draw a small number of elements. And a small 
array with a linear search (tracking used indices) would 
outperform that if you only want to draw say 8 elements. If you 
want to draw close to N elements then you would be better off 
just randomizing a full array (with elements from 0 to N-1). Or 
you could do all of these, start with linear search, then convert 
to a tree like search, then convert to full enumeration.


In general I don't think asymptotical analysis will do much good. 
I think you need to look on actual costs for typical N, P and 
different distributions of satisfied P, e.g.


cost of loop iteration: 10
average cost of P(x)=>false: 1
average cost of P(x)=>true: 1000
probability for P(a[i]) for each i

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Stanislav Blinov via Digitalmars-d]

On Monday, 1 May 2017 at 04:54:28 UTC, Andrei Alexandrescu wrote:

On 4/30/17 8:43 PM, Stanislav Blinov wrote:
On Sunday, 30 April 2017 at 21:43:26 UTC, Andrei Alexandrescu 
wrote:

On 04/27/2017 07:35 PM, Stanislav Blinov wrote:
IAllocator is too high level an interface, it doesn't carry 
any
information as to what type of memory it can allocate (so we 
can only
assume unshared), and does or does it not use GC (so we can 
only assume

GC).


Initially all fresh memory is unshared. Whether or not the 
user subsequently shares it is of no consequence to the 
allocator.


Why would we need any ISharedAllocator then?


The allocator itself may be shared across threads...


But it is no different in case of memory. Allocator that 
allocates shared memory should either return shared(void)[] or 
have an explicit interface (allocateShared et al.), not just have 
the  "you may cast result of allocate() to shared" somewhere in 
the docs. We should let the language do the work it can, not send 
us to RTFM. Hence my earlier statement that more interfaces are 
needed, as one possible (albeit not pretty) solution.

Re: [OT] Algorithm question

[Moritz Maxeiner via Digitalmars-d]

On Monday, 1 May 2017 at 09:58:39 UTC, Timon Gehr wrote:

On 01.05.2017 11:51, Moritz Maxeiner wrote:

[...]


This deterministically chooses 0. (uniform is right-exclusive.) 
I assume you mean uniform(0,2).


Yes.




[...]


Counterexample: [1,0,1,1].

The first element is chosen with probability 1/2, which is not 
1/3.


Dang. Serves me right for not doing the full analysis. Thanks for 
the counter example and sorry for wasting your time.





[...]


I don't understand this input model.



Since the idea was nonsense, it doesn't matter, anyway.

Re: [OT] Algorithm question

[Timon Gehr via Digitalmars-d]

On 01.05.2017 11:51, Moritz Maxeiner wrote:

On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:


Given a set A of n elements (let's say it's a random-access range of
size n, where n is relatively large), and a predicate P(x) that
specifies some subset of A of elements that we're interested in, what's
the best algorithm (in terms of big-O time complexity) for selecting a
random element x satisfying P(x), such that elements that satisfy P(x)
have equal probability of being chosen? (Elements that do not satisfy
P(x) are disregarded.)

Which elements of A satisfy P(x) is not known ahead of time, nor is the
relative proportion of elements that satisfy P(x) or not.



Works only with a random access range and I haven't done the full
analysis (and I'm a bit rusty on probability), but my first thought was
random divide and conquer:

ElementType!A* select(A,P)(A r)
{
  // Recursion anchor
  if (r.length == 1) {
if (P(r[0])) return r[0];
else return null;
  // Recurse randomly with p=0.5 into either the left, or right half of r
  } else {
ElementType!A* e;
ElementType!A[][2] half;
half[0] = r[0..floor(r.length/2)];
half[1] = r[ceil(r.length/2)..$];

ubyte coinFlip = uniform(0,1) > 0;


This deterministically chooses 0. (uniform is right-exclusive.) I assume 
you mean uniform(0,2).



// Recurse in one half and terminate if e is found there
e = select(half[coinFlip]);
if (e) return e;
// Otherwise, recurse into other half
return select(half[1 - coinFlip]);
  }
}

As stated above, I haven't done the full analysis, but intuitively
speaking (which can be wrong, of course), the p=0.5 recursion ought
satisfy the condition of elements satisfying P(x) being chosen
uniformly;


Counterexample: [1,0,1,1].

The first element is chosen with probability 1/2, which is not 1/3.


also intuitively, I'd expect the expected runtime for a
uniform distribution of elements satisfying P(x)  to be around O(log N).


I don't understand this input model.


Worst-case would be that it has to inspect every element in r once => O(N)

Re: [OT] Algorithm question

[Moritz Maxeiner via Digitalmars-d]

On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:


Given a set A of n elements (let's say it's a random-access 
range of

size n, where n is relatively large), and a predicate P(x) that
specifies some subset of A of elements that we're interested 
in, what's
the best algorithm (in terms of big-O time complexity) for 
selecting a
random element x satisfying P(x), such that elements that 
satisfy P(x)
have equal probability of being chosen? (Elements that do not 
satisfy

P(x) are disregarded.)

Which elements of A satisfy P(x) is not known ahead of time, 
nor is the

relative proportion of elements that satisfy P(x) or not.



Works only with a random access range and I haven't done the full 
analysis (and I'm a bit rusty on probability), but my first 
thought was random divide and conquer:


ElementType!A* select(A,P)(A r)
{
  // Recursion anchor
  if (r.length == 1) {
if (P(r[0])) return r[0];
else return null;
  // Recurse randomly with p=0.5 into either the left, or right 
half of r

  } else {
ElementType!A* e;
ElementType!A[][2] half;
half[0] = r[0..floor(r.length/2)];
half[1] = r[ceil(r.length/2)..$];

ubyte coinFlip = uniform(0,1) > 0;
// Recurse in one half and terminate if e is found there
e = select(half[coinFlip]);
if (e) return e;
// Otherwise, recurse into other half
return select(half[1 - coinFlip]);
  }
}

As stated above, I haven't done the full analysis, but 
intuitively speaking (which can be wrong, of course), the p=0.5 
recursion ought satisfy the condition of elements satisfying P(x) 
being chosen uniformly; also intuitively, I'd expect the expected 
runtime for a uniform distribution of elements satisfying P(x) to 
be around O(log N).
Worst-case would be that it has to inspect every element in r 
once => O(N)

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 08:42:05 UTC, John Colvin wrote:

I like this one (warning, just thought of, untested):

auto r = ... /* elements of A */
auto nRemaining = r.length;
while (nRemaining) {
auto i = uniform(0, nRemaining);
if (P(r[i])) return r[i];
else swap(r[i], r[--nRemaining]);
}



Yes, this is the standard text-book way of doing it, still O(N) 
of course. The other standard-text-book way is to generate an 
array of indexes and mutate that instead, still O(N). If you 
cache in a heap you get O(N log N).


Anyway, this kind of worst case analysis doesn't really help. And 
neither does average case, which will be O(1) assuming 50% match 
P.


So you need is to specify what kind of average case analysis you 
want. For instance expressed as f(N,S)  where N is the number of 
elements and S is the number of elements that satisfies P.

[Issue 17362] New: Don't infer return attribute for explicit scope arguments

[via Digitalmars-d-bugs]

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

  Issue ID: 17362
   Summary: Don't infer return attribute for explicit scope
arguments
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: n...@geany.org

auto f(scope Object i){return i;}

The above compiles with -dip1000 because parameter i is inferred as `return
scope`. As the author deliberately wrote `scope`, the compiler should error
when trying to return a scope parameter. This will help to catch bugs in
complex generic code.

--

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
Is there an algorithm for *incrementally* generating a random 
permutation of indices?


Does it exist? Yes, because you can build permutation tables for 
it, but you'll have to find the closed form for it that is 
efficient... Can you do that without selecting a specific N? It 
is easy for N=2 and N=3 at least.


E.g.

For array length 2 you get the 2 permutations: 0 1, 1 0
Then you just select one of them at random (you know the number 
of permutations)


So if it exists you'll should probably do a search for 
permutations. "How do I efficiently generate permutation number N"


Of course for smaller N you could generate a big array of bytes 
and compress it by having arrays of slices into it (as many 
permutations will share index sequences).

Re: [OT] Algorithm question

[John Colvin via Digitalmars-d]

On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
I'm been thinking about the following problem, and thought I'd 
pick the brains of the bright people around these parts...


Given a set A of n elements (let's say it's a random-access 
range of

size n, where n is relatively large), and a predicate P(x) that
specifies some subset of A of elements that we're interested 
in, what's
the best algorithm (in terms of big-O time complexity) for 
selecting a
random element x satisfying P(x), such that elements that 
satisfy P(x)
have equal probability of being chosen? (Elements that do not 
satisfy

P(x) are disregarded.)

Which elements of A satisfy P(x) is not known ahead of time, 
nor is the

relative proportion of elements that satisfy P(x) or not.

Note that A is considered to be immutable (swapping elements or
otherwise changing A is not allowed).

So far, I have come up with the following algorithms:

1) "Random shooting":

auto r = ... /* elements of A */
for (;;) {
auto i = uniform(0, r.length);
if (P(r[i])) return r[i];
}

   Advantages: If a large percentage of elements in A satisfy 
P(x), then
   the loop will terminate within a small number of iterations; 
if the
   majority of elements satisfy P(x), this will terminate well 
below n

   iterations.

   Disadvantages: If only a small percentage of elements 
satisfy P(x),
   then this loop could take arbitrarily long to terminate, and 
it will

   not terminate at all if no elements satisfy P(x).


You can recover O(n) calls to P by caching the results. You can 
recover O(n) for both P and rng by progressively removing 
elements from r or any other method that results in an easily 
samplable set of all elements of r not yet visited (and therefore 
possible candidates).


I like this one (warning, just thought of, untested):

auto r = ... /* elements of A */
auto nRemaining = r.length;
while (nRemaining) {
auto i = uniform(0, nRemaining);
if (P(r[i])) return r[i];
else swap(r[i], r[--nRemaining]);
}


3) Permutation walk:

auto r = ... /* elements of A */
foreach (i; iota(0 .. r.length).randomPermutation) {
if (P(r[i])) return r[i];
}
/* no elements satisfy P(x) */

   Advantages: if an element that satisfies P(x) is found 
early, the
   loop will terminate before n iterations. This seems like the 
best of

   both worlds of (1) and (2), except:

   Disadvantages: AFAIK, generating a random permutation of 
indices from
   0 .. n requires at least O(n) time, so any advantage we may 
have had

   seems to be negated.

Is there an algorithm for *incrementally* generating a random 
permutation of indices? If there is, we could use that in (3) 
and thus achieve the best of both worlds between early 
termination if an element satisfying P(x) is found, and 
guaranteeing termination after n iterations if no elements 
satisfying P(x) exists.



T


Yes. As a matter of fact it would be the logical extension of my 
algorithm above for when you can't or don't want to change r 
(again, only just thought of this, untested...):


auto r = ... /* elements of A */
auto indices = iota(r.length).array;
auto nRemaining = r.length;
while (nRemaining) {
auto i = uniform(0, nRemaining);
if (P(r[indices[i]])) return r[indices[i]];
else swap(indices[i], indices[--nRemaining]);
}

You could also do the same thing but with an array of pointers to 
elements of r instead of indices.

[Issue 11044] Escaping references to lazy argument are allowed

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

   Keywords||safe
 CC||n...@geany.org

--- Comment #2 from Nick Treleaven  ---
With dmd 2.074, -dip1000 the `dg = { return i; }` from comment 1 won't compile,
but the original lazy code still does.

--

Re: [OT] Algorithm question

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
Which elements of A satisfy P(x) is not known ahead of time, 
nor is the

relative proportion of elements that satisfy P(x) or not.


O(N) given P(x)===false for all x...

What you want is probably average case analysis, not worst case?

[Issue 15996] @safe allows escaping of ptrs to variables going out of scope

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||n...@geany.org
 Resolution|--- |FIXED

--- Comment #5 from Nick Treleaven  ---
Fixed as per comment 4, dmd 2.074 with -dip1000.

--

Re: DMD VS2017 Support

[Igor via Digitalmars-d]

On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote:

On Sunday, 30 April 2017 at 16:05:10 UTC, Igor wrote:


I should also mention that compiling using DUB works. It only 
doesn't work from VS.


Check your VisualD settings and make sure it has DMD path set 
up.

See under Tools>Options>Projects and solutions>Visual D Settings


That was it. It didn't occur to me that this was the problem 
because I payed closed attention during VisualD installation and 
saw it properly recognized where DMD was installed but for some 
reason the path wasn't set in Options. Once I did set it, compile 
and build worked. Thanks evilrat!


So in conclusion it seems the problem is in VisualD installation 
which doesn't set the path properly even though it recognizes 
where DMD is installed. Hope the author takes a look at this 
problem so beginners wanting to try D don't give up on a problem 
like this.

Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Sebastiaan Koppe via Digitalmars-d]

On Friday, 28 April 2017 at 22:18:54 UTC, Atila Neves wrote:
Done. I also added to the README that it has its own versions 
of the range constraints from Phobos that can be used with 
`@models`.


Atila


Example of an error message in the README would be great too.