DConf: three talk abstracts missing

[Joakim via Digitalmars-d]

For those thinking about watching the talks on the livestream, 
maybe these can be filled in?


http://dconf.org/2017/talks/buclaw.html
http://dconf.org/2017/talks/panel.html
http://dconf.org/2017/talks/alexandrescu.html

Re: [OT] Algorithm question

[H. S. Teoh via Digitalmars-d]

On Mon, May 01, 2017 at 05:03:17AM +, Jack Stouffer via Digitalmars-d wrote:
> On Monday, 1 May 2017 at 04:15:35 UTC, H. S. Teoh wrote:
> > 2) "Turtle walk":
> 
> I'd just like to point out that this algorithm doesn't satisfy
> 
> > such that elements that satisfy P(x) have equal probability of being
> > chosen
> 
> as the first element found in A will be chosen, and then each
> subsequent element has a decreasing probability of replacing the first
> element of P = 1/nSatisfy.

Actually, this is exactly why it *does* satisfy the requirement.

If there is exactly 1 element that satisfies P(x), then the probability
of it being picked is 1.

If there are 2 elements, the first element is picked with probability 1
initially, but the 2nd element has a 1/2 chance of replacing it, meaning
the overall probability distribution is 1/2 and 1/2.

If there are 3 elements, then by the time the 2nd element is processed,
the first 2 elements are equally likely to be currently chosen (with
probability 1/2 for each); when the 3rd element is found, it has 1/3
chance of replacing the previous choice, meaning there is a 2/3 chance
the previous choice prevails. In that case, the 2/3 chance is equally
distributed between the first two elements (they were picked with 1/2
and 1/2 probability), so the effective probability is 1/3 each after the
3rd element is processed.

In general, by the time you process the n'th element, the previous
elements would have had been picked with 1/(n-1) chance each, and the
n'th element would be picked with 1/n chance, meaning there is a (n-1)/n
chance the previous choice prevails. That (n-1)/n chance is equally
distributed among the previous (n-1) elements, so effectively they are
picked with 1/n chance each.

The key here is that the probability that the n'th element is *not*
picked is exactly (n-1)/n, which, by inductive hypothesis, must be
evenly distributed among the previous (n-1) candidates, thereby making
their *eventual* probability of remaining as the chosen element exactly
1/n.


T

-- 
Two wrongs don't make a right; but three rights do make a left...

Re: [OT] Algorithm question

[Jack Stouffer via Digitalmars-d]

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

2) "Turtle walk":


I'd just like to point out that this algorithm doesn't satisfy

such that elements that satisfy P(x) have equal probability of 
being chosen


as the first element found in A will be chosen, and then each 
subsequent element has a decreasing probability of replacing the 
first element of P = 1/nSatisfy.

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

[Andrei Alexandrescu via Digitalmars-d]

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, in which case its 
primitives need to be reentrant. -- Andrei

[OT] Algorithm question

[H. S. Teoh via Digitalmars-d]

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).

2) "Turtle walk":

auto r = ... /* elements of A */
int nSatisfy = 0;
ElementType!A currentChoice;
bool found = false;
foreach (e; r) {
if (P(e)) {
if (uniform(0, nSatisfy) == 0)
{
currentChoice = e;
found = true;
}
nSatisfy++;
}
}
if (found) return currentChoice;
else ... /* no elements satisfy P(x) */

   Advantages: If there is any element at all in A that satisfies P(x),
   it will be found. The loop always terminates after n iterations.

   Disadvantages: Even if 99% of elements in A satisfies P(x), we still
   have to traverse the entire data set before we terminate. (We cannot
   terminate before that, otherwise the probability of elements
   satisfying P(x) being selected will not be even.)

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

-- 
The early bird gets the worm. Moral: ewww...

[Issue 16044] __traits(allMembers) returns empty tuple for subpackages

[via Digitalmars-d-bugs]

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

Alexey Kulentsov  changed:

   What|Removed |Added

 CC||criman...@gmail.com

--- Comment #1 from Alexey Kulentsov  ---
For DMD64 D Compiler 2.074.0 result is:

abc/def/package.d-mixin-7(7): Deprecation: package abc.def is not accessible
here, perhaps add 'static import abc.def;'
tuple()

So abc.def package is not accessible from abc/def/package.d
But accessible if I move/rename file to abc/def.d and result is tuple("object",
"xyz", "_staticCtor1")

So it seems, for now, the problem is in the availability of the module, not in
the allMembers trait.

--

Re: DMD VS2017 Support

[evilrat via Digitalmars-d]

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

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

[Stanislav Blinov via Digitalmars-d]

On Monday, 1 May 2017 at 00:43:22 UTC, Stanislav Blinov wrote:


block_ = allocator_.allocate(T.sizeof);


Obviously, should be Block.sizeof, and


AllocatorInterface!AllocTraits allocator_;


should be AllocatorInterface!traits allocator_

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

[Stanislav Blinov via Digitalmars-d]

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? If we're to force 
users to rely on *documentation* whether or not they can cast 
allocated memory to shared, there is no point in static checks, 
they'll only get in the way of user's attempts to try and stitch 
together the pieces. They're on their own anyway at that point.


If we are to devise types with allocators as members instead 
of type
arguments, we need the additional information. Better to catch 
invalid
assignment at compile time than to chase down how a stack 
allocator from

one thread ended up in another.


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.


If we're type-erasing allocators, we have to have the ability to 
statically specify what traits we're interested in (i.e. *don't* 
want to erase). Otherwise, inference will not be of any help.
Consider an example, inspired by the discussion of Atila's 
automem library:


import std.experimental.allocator;
import std.algorithm.mutation : move;

// Allocator is not a type parameter
struct SmartPtr(T)
{
// we can infer all we need form A...
this(A, Args...)(A alloc, auto ref Args args)
if (isAllocatorImpl!A)
{
// ...but we immediately throw the inference away:
allocator_ = alloc;
block_ = cast(Block[])allocator_.allocate(Block.sizeof);
// SmartPtr logic snipped...
}

~this()
{
// ...SmartPtr logic snipped
allocator_.deallocate(block_);
}

private:
struct Block
{
size_t refCount;
void[T.sizeof] payload;
}

Block[] block_;
IAllocator allocator_;
}

struct Data {
~this() @nogc { /*...*/ }
// the rest of implementation is @nogc as well
}

struct MyType
{
// won't compile: IAllocator's methods aren't @nogc,
// so SmartPtr's dtor isn't either
this(SmartPtr!Data data) @nogc
{
data_ = move(data);
}

private:
SmartPtr!Data data_;
}

Obviously, IAllocator is not the tool for the job here. This 
calls for something like this:


enum AllocTraits
{
none  = 0x00,
nogc  = 0x01,
share = 0x02
}

alias AllocatorInterface(AllocTraits) = // ???

struct SmartPtr(T, AllocTraits traits = AllocTraits.none)
{
this(A, Args...)(A alloc, auto ref Args args)
{
// this should not compile if A isn't compatible
// with `traits`:
allocator_ = alloc;
block_ = allocator_.allocate(T.sizeof);
// SmartPtr logic snipped...
}

~this()
{
// ...SmartPtr logic snipped
allocator_.deallocate(block_);
}

private:
void[] block_;
AllocatorInterface!AllocTraits allocator_;
}

alias DataPtr = SmartPtr!(Data, AllocTraits.nogc);

struct MyType
{
this(DataPtr data) @nogc
{
data_ = move(data);
}

private:
DataPtr data_;
}

That *would* be able to rely on inference. Question is, what is 
AllocatorInterface? Should we push such type erasure to the users?

Re: alias this on module

[Jonathan Marler via Digitalmars-d]

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 
:)


-Steve


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


//
// File: main.d
//
import mymodule;

// now the symbol "x" refers to foo.x, and the symbol "baz" 
refers to foo.baz.

Re: alias this on module

[Steven Schveighoffer via Digitalmars-d]

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 :)

-Steve

alias this on module

[Jonathan Marler via Digitalmars-d]

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 

Re: How to correctly generate enums at compile time.

[jkpl via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 22:03:02 UTC, Kevin Balbas wrote:

On Sunday, 30 April 2017 at 21:31:22 UTC, jkpl wrote:

On Sunday, 30 April 2017 at 21:13:07 UTC, Kevin Balbas wrote:

On Sunday, 30 April 2017 at 20:58:36 UTC, jkpl wrote:

On Sunday, 30 April 2017 at 20:05:59 UTC, Kevin Balbas wrote:

Strangely enough, it does work fine in the test snippet,

[...]
My actual project uses dub/visuald for building, so I don't 
really tinker with file ordering.  Is this a thing that's 
supposed to happen?


Hell no !

Re: How to correctly generate enums at compile time.

[Kevin Balbas via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 21:31:22 UTC, jkpl wrote:

On Sunday, 30 April 2017 at 21:13:07 UTC, Kevin Balbas wrote:

On Sunday, 30 April 2017 at 20:58:36 UTC, jkpl wrote:

On Sunday, 30 April 2017 at 20:05:59 UTC, Kevin Balbas wrote:

Strangely enough, it does work fine in the test snippet,


As well if you import the snippet in another module. That's 
what i tried to tell.
try to reduce step by step; The problem cant be the stuff you 
mix.


I was able to fix the error by simplifying and slashing down my 
actual code to a few hundred lines and 4 modules (3 plus a stub 
main), and even then the error only goes away if I compile the 
modules in a very specific order with dmd.  Namely, both the 
main() file and the file containing the enum have to be compiled 
after all of the things that use the enum, and one of the two 
dependents has to be compiled before the other.  I have no idea 
*why* that's the case, but it seems to be.


My actual project uses dub/visuald for building, so I don't 
really tinker with file ordering.  Is this a thing that's 
supposed to happen?

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

[Andrei Alexandrescu via Digitalmars-d]

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. Allocators 
must, however, distinguish between reentrant and non-reentrant calls to 
the allocation primitives.


With regard to whether the memory is collectable or not we need some 
more thinking.



If we are to devise types with allocators as members instead of type
arguments, we need the additional information. Better to catch invalid
assignment at compile time than to chase down how a stack allocator from
one thread ended up in another.


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

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

[Andrei Alexandrescu via Digitalmars-d]

On 04/27/2017 07:12 PM, Moritz Maxeiner wrote:

On Thursday, 27 April 2017 at 20:04:32 UTC, Stanislav Blinov wrote:

On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5355

Andrei


And then we'd probably need INoGCAllocator and ISharedNOGCAllocator...


Wasn't one major selling point of compile time introspection / duck
typing that we could stop using interfaces such... naming schemes?


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

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

[Andrei Alexandrescu via Digitalmars-d]

On 04/27/2017 04:04 PM, Stanislav Blinov wrote:

On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5355

Andrei


And then we'd probably need INoGCAllocator and ISharedNOGCAllocator...


"shared" is a type qualifier essentially changing the type of the 
interface, so a separate interface is needed. For @nogc, simple variance 
is sufficient:


interface A
{
void fun();
}

class B : A
{
void fun() @nogc {}
}

That said, there are quite a few functions we should be able to qualify 
as @nogc from the get-go, e.g. empty, expand, alignment etc. Would you 
like to try a PR to that effect? Thanks!



Andrei

Re: How to correctly generate enums at compile time.

[jkpl via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 21:13:07 UTC, Kevin Balbas wrote:

On Sunday, 30 April 2017 at 20:58:36 UTC, jkpl wrote:

On Sunday, 30 April 2017 at 20:05:59 UTC, Kevin Balbas wrote:

Strangely enough, it does work fine in the test snippet,


As well if you import the snippet in another module. That's what 
i tried to tell.

try to reduce step by step; The problem cant be the stuff you mix.

Re: String Comparison Operator

[Xinok via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 19:05:18 UTC, bauss wrote:

On Sunday, 30 April 2017 at 16:15:41 UTC, Xinok wrote:

On Sunday, 30 April 2017 at 15:31:39 UTC, Jolly James wrote:

Is there a String Comparison Operator in D?


Yeah, just the usual comparison operators:

"abc" == "abc"
"abc" != "ABC"


~ is for string concatenation, i.e.:

"abc" ~ "def" == "abcdef"


Just to clarify.

It's not actually a string concatenation operator, it's an 
array appending operator.


Strings are just an alias for immutable(char)[] and not 
actually a type unlike other languages like C#, Java etc. where 
strings are objects.


In fact it doesn't have any operators that doesn't work with 
any other type of arrays. Just like functions such as replace 
etc. aren't necessarily string functions, but works with any 
type of arrays.


Regarding concatenation vs appending, it's kind of both depending 
on the type of the operands. What I mean is all of the following 
are valid:


[10, 20] ~ [30, 40] == [10, 20, 30, 40]  // Concatenation
[10, 20] ~ 30   == [10, 20, 30]  // Appending
10 ~ [20, 30]   == [10, 20, 30]  // Prepending

Re: alias can't find symbol or can't use symbol

[Jerry via Digitalmars-d-learn]

To me this seems like a bug.

Re: How to correctly generate enums at compile time.

[Kevin Balbas via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 20:58:36 UTC, jkpl wrote:

On Sunday, 30 April 2017 at 20:05:59 UTC, Kevin Balbas wrote:
I've got the following code snippet, which almost does what I 
want.


struct TaggedType {}

@TaggedType
struct Foo {}

@TaggedType
struct Bar {}

string GenerateTypeEnum()
{
string enumString = "enum TypeEnum {";
foreach (name; __traits(allMembers, mixin(__MODULE__)))
{
import std.traits;
static if (hasUDA!(mixin(name), TaggedType))
{
enumString ~= name;
enumString ~= "Type,";
}
}
enumString ~= "}";
return enumString;
}

// generates enum TypeEnum {FooType,BarType,}
mixin(GenerateTypeEnum());

This works great, except that TypeEnum isn't accessible from 
other modules (undefined identifier 'TypeEnum'), which is kind 
of the point of doing this (I'm using the enum as a 
system-wide tag for inter-thread communication).  I can 
imagine why this would be the case, but it's a pretty serious 
problem.  Is there a way to do this?


if i put your sniped in b.d and import in a.d b then i'm able 
to access TypeEnum.
You r problem must be something stupid that's not related to 
UDA/mixins.


That leads to this question (sorry) but at least do you import 
the module that contains TypeEnum ?


Yes, and in fact, if I manually comment out the code (in my 
actual program, not the test program) in the same module and 
replace it with a hard-coded enum, the other code can access it 
perfectly.  I wouldn't be surprised if it was something stupid, 
but I'm not even sure what could go wrong between those two 
cases.  I figured it was some kind of ordering thing, but I 
honestly have no idea.


Strangely enough, it does work fine in the test snippet, so I'm 
trying to figure out what could be going on since I literally 
copied the function verbatim from my test program to my main one. 
 Now that I've realized this I'm working on how to repro it in 
the smaller program.

Re: How to correctly generate enums at compile time.

[jkpl via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 20:05:59 UTC, Kevin Balbas wrote:
I've got the following code snippet, which almost does what I 
want.


struct TaggedType {}

@TaggedType
struct Foo {}

@TaggedType
struct Bar {}

string GenerateTypeEnum()
{
string enumString = "enum TypeEnum {";
foreach (name; __traits(allMembers, mixin(__MODULE__)))
{
import std.traits;
static if (hasUDA!(mixin(name), TaggedType))
{
enumString ~= name;
enumString ~= "Type,";
}
}
enumString ~= "}";
return enumString;
}

// generates enum TypeEnum {FooType,BarType,}
mixin(GenerateTypeEnum());

This works great, except that TypeEnum isn't accessible from 
other modules (undefined identifier 'TypeEnum'), which is kind 
of the point of doing this (I'm using the enum as a system-wide 
tag for inter-thread communication).  I can imagine why this 
would be the case, but it's a pretty serious problem.  Is there 
a way to do this?


if i put your sniped in b.d and import in a.d b then i'm able to 
access TypeEnum.
You r problem must be something stupid that's not related to 
UDA/mixins.


That leads to this question (sorry) but at least do you import 
the module that contains TypeEnum ?

Re: String Comparison Operator

[ag0aep6g via Digitalmars-d-learn]

On 04/30/2017 09:05 PM, bauss wrote:

On Sunday, 30 April 2017 at 16:15:41 UTC, Xinok wrote:

[...]

~ is for string concatenation, i.e.:

[...]

It's not actually a string concatenation operator, it's an array
appending operator.


Appending is related but distinct. `~` does concatenation. `~=` does 
appending.


https://dlang.org/spec/arrays.html#array-concatenation


Strings are just an alias for immutable(char)[] and not actually a type
unlike other languages like C#, Java etc. where strings are objects.


I get what you mean, but while we're splitting hairs: `string` 
definitely is a type. It's the same type as `immutable(char)[]`.



In fact it doesn't have any operators that doesn't work with any other
type of arrays. Just like functions such as replace etc. aren't
necessarily string functions, but works with any type of arrays.


Not an operator, but `foreach` has special support for transcoding 
between the different UTF variants.


Regarding functions, narrow strings (`string`, `wstring`) are special 
cased all over phobos. It's because as ranges they have dchar elements, 
but as arrays they have char/wchar elements. std.array.replace [1] also 
mentions strings in its signature because of this.




[1] https://dlang.org/phobos/std_array.html#.replace

Re: Stack Trace format

[Szabo Bogdan via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 20:31:09 UTC, Szabo Bogdan wrote:

Hi,

I noticed that on different platforms the 
`object.Throwable.TraceInfo` has different formats. A program 
compiled on osx with ldc2 has all the TraceInfo empty... Why?


I want to parse those strings or somehow iterate trough all the 
stack elements, but if I get a different format on different 
platforms it's not that easy to determine at what position in 
the string is the address or the function name.


I would appreciate if anyone have an idea of how I can do this 
without a big headache...


Thanks!


Actually I found the `defaultTraceHandler` here:

https://github.com/dlang/druntime/blob/7caaf7cbb699a2a1944b2ac087c3b07d23db6802/src/core/runtime.d#L534

Re: DIP 1007 Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

On 4/28/17 4:31 AM, Olivier FAURE wrote:

On Wednesday, 26 April 2017 at 11:26:19 UTC, Steven Schveighoffer wrote:

I'm wondering if you actually wrote this? It seems to be quoted.


That was a quote from the DIP. (guess I should have used a colon)


Ah, OK. Sorry for the confusion, I wasn't sure where it came from.

-Steve

Stack Trace format

[Szabo Bogdan via Digitalmars-d-learn]

Hi,

I noticed that on different platforms the 
`object.Throwable.TraceInfo` has different formats. A program 
compiled on osx with ldc2 has all the TraceInfo empty... Why?


I want to parse those strings or somehow iterate trough all the 
stack elements, but if I get a different format on different 
platforms it's not that easy to determine at what position in the 
string is the address or the function name.


I would appreciate if anyone have an idea of how I can do this 
without a big headache...


Thanks!

[Issue 17141] Type Inference Incorrectly Converts Characters to Integers

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #8 from Steven Schveighoffer  ---
I'm not sure the cure is better than the disease.

If CommonType!(dchar, char) becomes dchar, then chaining together a range of
dchar with a range of char *integer promotes* the char range to dchar. It
doesn't decode it!

--

[Issue 17358] [REG 2.074.0] std.stdio.File.lockingTextWriter.put no longer accepts chains of characters

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #4 from Steven Schveighoffer  ---
Yes, the bug that the PR fixed was to prevent lockingTextWriter.put from taking
an arbitrary byte, ubyte, short, ushort, int, or uint range and integer
promoting the elements to dchar. It was decided to allow ubyte[] specifically
(and write it directly as an array of ubytes), because of the inability to use
byChunk and lockingBinaryWriter to achieve a direct copy of a file.

IMO, the whole system is really messed up. It doesn't make sense to accept a
range of arbitrary bytes to a text writer, but lockingBinaryWriter changes the
stream from a text to binary (Which means something for Windows newlines).

I'm not sure of a "correct" way to fix this regression (which really is
erroneous behavior which happened not to blow up). If the identified CommonType
bug is fixed, we still are dealing with integer promoting chars to dchars
inside chain, which isn't right either.

--

How to correctly generate enums at compile time.

[Kevin Balbas via Digitalmars-d-learn]

I've got the following code snippet, which almost does what I 
want.


struct TaggedType {}

@TaggedType
struct Foo {}

@TaggedType
struct Bar {}

string GenerateTypeEnum()
{
string enumString = "enum TypeEnum {";
foreach (name; __traits(allMembers, mixin(__MODULE__)))
{
import std.traits;
static if (hasUDA!(mixin(name), TaggedType))
{
enumString ~= name;
enumString ~= "Type,";
}
}
enumString ~= "}";
return enumString;
}

// generates enum TypeEnum {FooType,BarType,}
mixin(GenerateTypeEnum());

This works great, except that TypeEnum isn't accessible from 
other modules (undefined identifier 'TypeEnum'), which is kind of 
the point of doing this (I'm using the enum as a system-wide tag 
for inter-thread communication).  I can imagine why this would be 
the case, but it's a pretty serious problem.  Is there a way to 
do this?

Re: CTFE Status 2

[H. S. Teoh via Digitalmars-d]

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

-- 
Life begins when you can spend your spare time programming instead of watching 
television. -- Cal Keegan

Re: DMD VS2017 Support

[Mike B Johnson via Digitalmars-d]

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

On Sunday, 30 April 2017 at 16:31:13 UTC, John Chapman wrote:


Here are mine, if it helps:



I tried but still the same problem. I also tried reinstalling 
VisualD after changing sc.ini in DMD but that didn't help 
either.


You are going to have to figure it out. Visual Studio does some 
stupid path stuff that doesn't make any sense really(seems like 
it could do a much better job).


What you could do is:

1. Create a "library" folder.

e.g.,

C:\DMD\Libs\Coff\x86
C:\DMD\Libs\Coff\x64
C:\DMD\Libs\OMF\x86
C:\DMD\Libs\OMF\x64 <- not used as there is no x64 omf


2. Point sc.ini to these.

3. Copy the lib files from the VS or win SDK to these folders.

4. Do the magic that it takes to get it to work(which is finding 
the right libs that are needed, using procmon to see where dmd is 
looking, etc). This involves building and checking the errors 
then trying to resolve them.



Once done, you have a solid set of libs that once works, won't 
change.  When you update VS you can update the libs here and 
there but it is not needed very often.


Sometimes you'll have to pull in different libs from different 
versions and such. DMD comes with the some libs that you can use 
for x86.


Once you get it working you shouldn't have to mess with it much. 
If you accidentally overwrite sc.ini(which is ridiculous that it 
does this on install), you know EXACTLY where the libs are and 
don't have to go hunt for them again. If you want, you can use 
junctions instead of copying but these might need to be updated 
again when VS changes.

Re: protected behaviour on base class member access from another module

[Boris-Barboris via Digitalmars-d-learn]

Ok, sorry, look's like that was always the case in C++, so it's 
too late to question it. I'll just elevate it to package, I guess.

Re: String Comparison Operator

[bauss via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 16:15:41 UTC, Xinok wrote:

On Sunday, 30 April 2017 at 15:31:39 UTC, Jolly James wrote:

Is there a String Comparison Operator in D?


Yeah, just the usual comparison operators:

"abc" == "abc"
"abc" != "ABC"


~ is for string concatenation, i.e.:

"abc" ~ "def" == "abcdef"


Just to clarify.

It's not actually a string concatenation operator, it's an array 
appending operator.


Strings are just an alias for immutable(char)[] and not actually 
a type unlike other languages like C#, Java etc. where strings 
are objects.


In fact it doesn't have any operators that doesn't work with any 
other type of arrays. Just like functions such as replace etc. 
aren't necessarily string functions, but works with any type of 
arrays.

Re: interfacing Cpp - GCC Dual ABI abi_tag in name mangling

[via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 11:35:54 UTC, Jacob Carlborg wrote:
You can use pragma(mangle, "some mangling"); to set the mangled 
name of a symbol.


that's a quick hack, but sooner or later dmd needs to add some 
rules for this in the internal cpp mangler, since gcc is the main 
compiler in gnu/linux. at least provide an @abi_tag attribute or 
something the user can put inside a version condition.

[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

steven kladitis  changed:

   What|Removed |Added

   Keywords||performance

--

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

[via Digitalmars-d-bugs]

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

  Issue ID: 17361
   Summary: latest windows 10 insider preview and dmd no longer
runs.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: steven_kladi...@yahoo.com

I just installed the latest Insider Preview of Windows 10 and DMD no longer
runs at all. It just comes up and sits there in a window. I have tried
reinstalling it several times. The installer runs fine. Several Times. :):)
This is my current path
PATH=C:\D\dmd2\windows\bin
C:\ProgramData\Oracle\Java\javapath
c:\oracle\product\12.2.0\dbhome_64\bin
C:\Program Files (x86)\Intel\iCLS Client\
C:\Program Files\Intel\iCLS Client\
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\
C:\Program Files\Microsoft SQL Server\120\Tools\Binn\
C:\Program Files\uncrustify
C:\Program Files (x86)\QuickTime\QTSystem\
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL
C:\Program Files\Intel\Intel(R) Management Engine Components\DAL
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT
C:\Program Files\Intel\Intel(R) Management Engine Components\IPT
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\
C:\Program Files\IDM Computer Solutions\UltraEdit
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\
C:\Program Files (x86)\nodejs\
C:\Program Files\Microsoft\Web Platform Installer\
C:\Program Files (x86)\Microsoft Emulator Manager\1.0\
C:\Program Files\TortoiseSVN\bin
C:\Program Files\IDM Computer Solutions\UltraCompare
C:\Users\steven\AppData\Local\Microsoft\WindowsApps
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\
C:\Program Files (x86)\dub
C:\Program Files (x86)\Skype\Phone\
C:\D\dmd2\windows\bin

I have tried putting the dmd path in front and everywhere in between.




dub and dmd do not run in the 
c:\d\dmd2\windows\bin directory

--

protected behaviour on base class member access from another module

[Boris-Barboris via Digitalmars-d-learn]

Hi!

I have a base class in module A:

module A;
...
class GuiElement: GuiComponent
{
protected
{
GuiElement _parent;
...
}

template isGuiElement(T)
{
enum isGuiElement = is(T: GuiElement);
}
...


and derived class in module B:

module B;
...
class Div(uint dim, uint odim): GuiElement
{
protected GuiElement[] children;

this(Children...)(GuiManager manager, Children kids)
if (allSatisfy!(isGuiElement, Children))
{
super(manager);
children = [kids];
this._parent = null;   <- This works
foreach (kid; children)
	kid._parent = this;<- Error: class A.GuiElement 
member _parent is not accessible



A couple of questions:
1). Is this intended?
2). If yes, why? What is the reasoning behind such restriction? 
Quoting the docs: "...a symbol can only be seen by members of the 
same module, or by a derived class...".
3). What does the cryptic "If accessing a protected instance 
member through a derived class member function, that member can 
only be accessed for the object instance which can be implicitly 
cast to the same type as ‘this’" mean?
Let's say B derives from A, and B instance has a method that 
accesses A.protected_member inside of it. What does member access 
have to do with it? Why does this sentence jump from member to 
method, back to member, and then to some object that was never 
mentioned before? Objects don't request access, statements do. 
`this` of who?

[Issue 5212] no escape analysis for typesafe variadic function arguments

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

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

--- Comment #18 from Nick Treleaven  ---
Mentioning -dip1000 so Walter finds this.

--

Re: DMD VS2017 Support

[Igor via Digitalmars-d]

On Sunday, 30 April 2017 at 16:31:13 UTC, John Chapman wrote:


Here are mine, if it helps:



I tried but still the same problem. I also tried reinstalling 
VisualD after changing sc.ini in DMD but that didn't help either.

[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

 CC||n...@geany.org

--- Comment #2 from Nick Treleaven  ---
Seems to work with v2.074.0, -dip1000.

--

[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #15 from Nick Treleaven  ---
(In reply to Don from comment #9)
> Implicit conversion from int to bool is indeed rather odd. Do we really need
> it? Initially, literal 0 and 1 sound like acceptable ways of writing 'false'
> and 'true', but constant folding makes it much harder to justify.

https://github.com/dlang/dmd/pull/6404

--

Re: DMD VS2017 Support

[John Chapman via Digitalmars-d]

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

On Sunday, 30 April 2017 at 15:53:07 UTC, Mike Parker wrote:

On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote:



I tried updating sc.ini to new paths but I still get this 
error. Can someone offer some advice?


Which paths did you set?


These are the ones I changed:

VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC\Tools\MSVC\14.10.25017\

UCRTVersion=10.0.15063.0

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe

PATH=%PATH%;%VCINSTALLDIR%\bin\HostX64\x64

LIB=%LIB%;"%VCINSTALLDIR%\lib\x64"

Same for x86 environment, except, of course I replaced x64 with 
x86 in the values.


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


Here are mine, if it helps:

VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC

WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10
UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10
UCRTVersion=10.0.15063.0
LINKCMD=%VCINSTALLDIR%\Tools\MSVC\14.10.25017\bin\HostX64\x64\link.exe
PATH=%PATH%;%VCINSTALLDIR%\Tools\MSVC\14.10.25017\bin\HostX64\x64
LIB=%LIB%;"%VCINSTALLDIR%\Tools\MSVC\14.10.25017\lib\x64"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"

Re: String Comparison Operator

[tcak via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 15:31:39 UTC, Jolly James wrote:

Is there a String Comparison Operator in D?


You normally use double equation marks (==) to do that.

auto name = "Jack";
if( name == "Jack" ) writeln("Hi Jack!");

Re: String Comparison Operator

[Xinok via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 15:31:39 UTC, Jolly James wrote:

Is there a String Comparison Operator in D?


Yeah, just the usual comparison operators:

"abc" == "abc"
"abc" != "ABC"


~ is for string concatenation, i.e.:

"abc" ~ "def" == "abcdef"

Re: DMD VS2017 Support

[Igor via Digitalmars-d]

On Sunday, 30 April 2017 at 15:53:07 UTC, Mike Parker wrote:

On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote:



I tried updating sc.ini to new paths but I still get this 
error. Can someone offer some advice?


Which paths did you set?


These are the ones I changed:

VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC\Tools\MSVC\14.10.25017\

UCRTVersion=10.0.15063.0

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe

PATH=%PATH%;%VCINSTALLDIR%\bin\HostX64\x64

LIB=%LIB%;"%VCINSTALLDIR%\lib\x64"

Same for x86 environment, except, of course I replaced x64 with 
x86 in the values.


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

Re: alias can't find symbol or can't use symbol

[Carl Sturtivant via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 02:19:29 UTC, bauss wrote:

What exactly did you expect here?

'n' is not in the scope of 'outer'.

'n' is in the scope of 'member'.

Of course it works with 'x.n' since 'x' points to the 'member' 
declared inside 'outer'.


I mean it would have worked with classes, but structs are 
different does not have any type of actual inheritance, which 
is what you're trying to achieve.


```
class member {
int n;
}

class outer : member {
alias n2 = n; // Ok ...
}
```


It did NOT work with x.n as I asserted. And `alias x this` brings 
n into the scope of outer. So your reply makes no sense.

Re: String Comparison Operator

[無 via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 15:31:39 UTC, Jolly James wrote:

Is there a String Comparison Operator in D?


~

Re: DMD VS2017 Support

[Mike Parker via Digitalmars-d]

On Sunday, 30 April 2017 at 14:56:44 UTC, Igor wrote:



I tried updating sc.ini to new paths but I still get this 
error. Can someone offer some advice?


Which paths did you set?

String Comparison Operator

[Jolly James via Digitalmars-d-learn]

Is there a String Comparison Operator in D?

Re: DMD VS2017 Support

[Igor via Digitalmars-d]

On Saturday, 22 April 2017 at 02:46:30 UTC, Mike Parker wrote:

On Saturday, 22 April 2017 at 02:39:41 UTC, evilrat wrote:



Also VS 2017 is much more modular now, so its now lighter than 
ever before.

but of course for C++ (and D) you still need Windows SDK.


The SDK stuff is installed with VS.



IIRC D also can be used without VS or WinSDK at all, just 
forget about m32mscoff and x64 builds


Yes, that is correct. But that comes with its own headaches.


I had a working VS 2015 with VisualD and DMD. Today I uninstalled 
VS2015 and VisualD, then installed VS2017 and latest VisualD but 
when I create new D windows app and try to run it I get this 
error:


Command Line

set PATH=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86;C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE;C:\Program Files (x86)\Windows Kits\8.1\bin\x86;.\windows\bin;%PATH%
dmd -g -debug -X -Xf"Win32\Debug\testapp.json" 
-deps="Win32\Debug\testapp.dep" -c -of"Win32\Debug\testapp.obj" 
winmain.d

if errorlevel 1 goto reportError

set LIB=
echo. > D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo 
"Win32\Debug\testapp.obj","Win32\Debug\testapp.exe","Win32\Debug\testapp.map",ole32.lib+ >> D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo kernel32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo user32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo comctl32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo comdlg32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo user32.lib+ >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg
echo kernel32.lib/NOMAP/CO/NOI/DELEXE /SUBSYSTEM:WINDOWS >> 
D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg


"C:\Program Files (x86)\VisualD\pipedmd.exe" -deps 
Win32\Debug\testapp.lnkdep link.exe 
@D:\git\testapp\testapp\Win32\Debug\testapp.build.lnkarg

if errorlevel 1 goto reportError
if not exist "Win32\Debug\testapp.exe" (echo 
"Win32\Debug\testapp.exe" not created! && goto reportError)


goto noError

:reportError
echo Building Win32\Debug\testapp.exe failed!

:noError
Output

Microsoft (R) Incremental Linker Version 14.10.25019.0
Copyright (C) Microsoft Corporation.  All rights reserved.

"Win32\Debug\testapp.obj,Win32\Debug\testapp.exe,Win32\Debug\testapp.map,ole32.lib+"
kernel32.lib+
user32.lib+
comctl32.lib+
comdlg32.lib+
user32.lib+
kernel32.lib/NOMAP/CO/NOI/DELEXE /SUBSYSTEM:WINDOWS
LINK : fatal error LNK1181: cannot open input file 
'Win32\Debug\testapp.obj,Win32\Debug\testapp.exe,Win32\Debug\testapp.map,ole32.lib+'

Building Win32\Debug\testapp.exe failed!

I tried updating sc.ini to new paths but I still get this error. 
Can someone offer some advice?

Re: Transitive bit-packing of fields

[Per Nordlöw via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 13:22:49 UTC, Stefan Koch wrote:

On Sunday, 30 April 2017 at 11:02:52 UTC, Nordlöw wrote:

Have anybody found a way to do transitive packing of bitfields?

For instance, in


import std.bitmanip : bitfields;

struct X
{
// one bit too many to fit in one byte
mixin(bitfields!(bool, `a`, 1,
 bool, `b`, 1,
 ubyte, `c`, 7,
 ubyte, `_pad`, 7);
}

struct Y
{
// one unused bit
mixin(bitfields!(ubyte, `d`, 7,
 ubyte, `_pad`, 1);
}

struct XY
{
X x;
Y y;
}


`XY` will currently occupy 4 bytes, when only 1+1+7+7=16 bits 
are actually used in `a`, `b`, `c` and `d`.


Rust just got support for this.


You'd have to write your own template to do it; it's easy 
though :)


Yeah, I thought so too. The question then becomes I have to write 
my own version of bitfields that can introspect the bitsize of 
it's arguments via some new trait bitsizeOf.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

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.

Re: Transitive bit-packing of fields

[Stefan Koch via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 11:02:52 UTC, Nordlöw wrote:

Have anybody found a way to do transitive packing of bitfields?

For instance, in


import std.bitmanip : bitfields;

struct X
{
// one bit too many to fit in one byte
mixin(bitfields!(bool, `a`, 1,
 bool, `b`, 1,
 ubyte, `c`, 7,
 ubyte, `_pad`, 7);
}

struct Y
{
// one unused bit
mixin(bitfields!(ubyte, `d`, 7,
 ubyte, `_pad`, 1);
}

struct XY
{
X x;
Y y;
}


`XY` will currently occupy 4 bytes, when only 1+1+7+7=16 bits 
are actually used in `a`, `b`, `c` and `d`.


Rust just got support for this.


You'd have to write your own template to do it; it's easy though 
:)

Re: will ddmd in standard library

[Jacob Carlborg via Digitalmars-d]

On 2017-04-30 09:29, ANtlord wrote:

Hello! I see documentation of pre-release version of standard library.
It has section ddmd. Does it mean that we will get std library with
ddmd? Does it mean we will get a powerful tool for making analysis tools
for D?


No, that's just the generated documentation for the compiler.

--
/Jacob Carlborg

Re: interfacing Cpp - GCC Dual ABI abi_tag in name mangling

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-04-29 20:08, سليمان السهمي (Soulaïman Sahmi) wrote:

GCC has this attribute called abi_tag that they put on any function that
returns std::string or std::list, for the rational behind that read
here:https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html .
the special thing with this attribute is that it adds something to the
name mangling of your function, and I don't know how to represent that
in D.
for example the cpp function "std::string func()" will be mangled as
"func[abi:cxx11]()".
any ideas?


You can use pragma(mangle, "some mangling"); to set the mangled name of 
a symbol.


--
/Jacob Carlborg

Re: Problem with using readln.

[Ivan Kazmenko via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 02:07:48 UTC, JV wrote:
Hello i'm kinda new to D language and i wanted to make a simple 
program
but somehow my input does no go to my if statements and just 
continues to ask for the user to input.Kindly help me


One way would be:

import std.stdio;
int x;
readf (" %s", );

The "%s" means "default format for the type", which is I believe 
"%d" (decimal) for the int type.  The space before "%s" is to 
skip all whitespace before the actual input, it will matter when 
you read your second integer:


readf ("%s%s", , ); // error, got space for y instead of 
a digit

readf ("%s %s", , ); // ok

Another way is:

import std.conv, std.stdio, std.string;
int x = readln.strip.to!int;

Here, we read the line with readln, strip the trailing whitespace 
with strip, and convert the resulting string to an int with 
to!int.


Also, you might want to look at the corresponding chapter in Ali 
Cehreli's book:

http://ddili.org/ders/d.en/input.html

Ivan Kazmenko.

Transitive bit-packing of fields

[Nordlöw via Digitalmars-d-learn]

Have anybody found a way to do transitive packing of bitfields?

For instance, in


import std.bitmanip : bitfields;

struct X
{
// one bit too many to fit in one byte
mixin(bitfields!(bool, `a`, 1,
 bool, `b`, 1,
 ubyte, `c`, 7,
 ubyte, `_pad`, 7);
}

struct Y
{
// one unused bit
mixin(bitfields!(ubyte, `d`, 7,
 ubyte, `_pad`, 1);
}

struct XY
{
X x;
Y y;
}


`XY` will currently occupy 4 bytes, when only 1+1+7+7=16 bits are 
actually used in `a`, `b`, `c` and `d`.


Rust just got support for this.

will ddmd in standard library

[ANtlord via Digitalmars-d]

Hello! I see documentation of pre-release version of standard 
library. It has section ddmd. Does it mean that we will get std 
library with ddmd? Does it mean we will get a powerful tool for 
making analysis tools for D?


And one more question. Standard library be without ddmd very long 
time. Will it get ddmd because compiler license has been changed 
by Boos license?


Thanks. Sorry if my English is not clear.

[Issue 17360] New: std.range.only doesn't allow ref access

[via Digitalmars-d-bugs]

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

  Issue ID: 17360
   Summary: std.range.only doesn't allow ref access
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

This a pain because it means things like this don't work:

int[] a = [1,2,3];
only(a).front.popFront();

Error: template std.range.primitives.popFront cannot deduce function from
argument types !()(int[]), candidates are:
std/range/primitives.d(2084):std.range.primitives.popFront(T)(ref T[]
a) if (!isNarrowString!(T[]) && !is(T[] == void[]))
std/range/primitives.d(2107):std.range.primitives.popFront(C)(ref C[]
str) if (isNarrowString!(C[]))

--

Re: Problem with using readln.

[arturg via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 05:53:09 UTC, Andrew Edwards wrote:

string line;
parse!int((line = readln)).writeln;



is there a reason you mix normal call and ufc or just some style?
you can do this and remove some ()

(line = readln).parse!int.writeln;