Re: How to detect if an array if dynamic or static

[Ali Çehreli via Digitalmars-d-learn]

On 02/24/2016 08:44 PM, mahdi wrote:
> On Wednesday, 24 February 2016 at 22:38:04 UTC, Adam D. Ruppe wrote:
>> On Wednesday, 24 February 2016 at 21:48:14 UTC, mahdi wrote:
>>> How can we detect is `array` is static (fixed size) or dynamic,
>>> inside the function body?
>>
>> `array` there is always dynamic because it is not of a fixed size type.
>>
>> Why do you want to know though?
>
> I thought we can simply denote `int[] x` in case we have an array
> argument in D functions. So according to your answer if a function
> expects a static array, it has to specify size of array in parameter
> declaration:
>
> void diss(int[3] array) ...  //this expects a static array of size 3
> void diss(int[] array) ...  //this expects a dynamic array
>
> is this correct?

Yes.

Note that static arrays are value types. So, if the parameter is int[3], 
then the argument will be copied. However, you can still take it by 
reference (with the ref keyword):


import std.stdio;

void diss(ref int[3] array) {
writeln(typeof(array).stringof);
}

void diss(int[] array) {
writeln(typeof(array).stringof);
}

void main() {
int[3] arr;
diss(arr);
}

Prints:

int[3]

And a reminder that rvalues cannot be bound to ref in D. So, 'ref 
int[3]' may not be usable in your case.


Ali

Re: Dynamic pitch shift

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 17:52:39 UTC, Guillaume Piolat 
wrote:
Though it isn't fantastic aliasing-wise on the last octave, I 
should try something than power-of-2s next time I need it.


Why would it help to not use 2^n sized tables? I guess you could 
compute everything at 88khz and decimate...

Re: C++ UFCS update

[Walter Bright via Digitalmars-d]

On 2/24/2016 9:43 PM, Ola Fosheim Grøstad wrote:

You're an obnoxious kid. :-)


Such statements are not welcome here. Please stop.

[OT] MS bought Xamarin

[Joakim via Digitalmars-d]

Looks like the competition for D as a cross-mobile language just 
got more serious:


https://www.thurrott.com/dev/64861/microsoft-finally-buys-xamarin

Re: C++ UFCS update

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 24 February 2016 at 22:55:11 UTC, Timon Gehr wrote:
You misunderstand what that part of the sentence refers to. 
(It's what I quoted.)


This is what you quoted:

«I find it ironic that Walter objects to reusing operators such 
as "<<"  while he is reusing "!" for templates»




You might want to keep those aspects to yourself or express


You don't get to tell me what I want or do not want to express. 
You're an obnoxious kid. :-)




their subjectivity more explicitly if you don't want them to be


"I find it ironic".

What more do you need?


In the context of C, "*" means either "dereference" or 
"multiply". "&" means either "take address" or "bitwise and".


And D blindly copies those mistakes. How does C's mistakes have 
any relevance to this?



Also, I'm not defending anything. I was attacking annoying 
rhetoric.


I find it ironic that you keep trying to make your own 
subjectivity look objective when it is rather obvious that your 
are engaging in blatant advocacy which just sement the idea that 
the design rationale behind D2's syntax is sound. It isn't. It 
breaks with basic usability principles.


The usability of D is not improving, and complaining about other 
languages' minor issues won't fix it. There is way too much 
resistance to fixing the language, both interface and semantics. 
That keeps D at a hobby level.


Or to put it bluntly: C, C++ and Rust having crappy syntaxes does 
not make D look a whole lot better. In order to do better, you 
have to be better. C/C++ are bogged down with legacy. There is no 
reason for D to be.


What keeps D from improving comes down to this: stubborn 
ignorance.


Offensive, but true.

Re: tell if __traits(allMembers, ... ) is an enum (not manifest constant)

[Nicholas Wilson via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 04:50:14 UTC, Nicholas Wilson 
wrote:
On Thursday, 25 February 2016 at 04:32:24 UTC, Adam D. Ruppe 
wrote:
On Thursday, 25 February 2016 at 04:25:25 UTC, Nicholas Wilson 
wrote:

foreach(m; __traits(allMembers, ...)
{
static if(is(m== enum))
}



That's close but not quite there... try

static if(is(typeof(__traits(getMember, Item, m)) == enum))

for member variables, or if you are looking at a type itself 
youcan leave off the typeof() bit.


what is this black magic???

static if(is(typeof(__traits(getMember, vulkan_input, m)) == 
enum))

{
writeln(typeof(__traits(getMember, vulkan_input, 
m))).stringof; //fails to compile

writeln(m); //prints nothing
}


oops should be
writeln(typeof(__traits(getMember, vulkan_input,  m)).stringof);
that compiles but still prints nothing

Re: tell if __traits(allMembers, ... ) is an enum (not manifest constant)

[Nicholas Wilson via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 04:32:24 UTC, Adam D. Ruppe 
wrote:
On Thursday, 25 February 2016 at 04:25:25 UTC, Nicholas Wilson 
wrote:

foreach(m; __traits(allMembers, ...)
{
static if(is(m== enum))
}



That's close but not quite there... try

static if(is(typeof(__traits(getMember, Item, m)) == enum))

for member variables, or if you are looking at a type itself 
youcan leave off the typeof() bit.


what is this black magic???

static if(is(typeof(__traits(getMember, vulkan_input, m)) == 
enum))

{
writeln(typeof(__traits(getMember, vulkan_input, 
m))).stringof; //fails to compile

writeln(m); //prints nothing
}

Re: How to detect if an array if dynamic or static

[mahdi via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 22:38:04 UTC, Adam D. Ruppe 
wrote:

On Wednesday, 24 February 2016 at 21:48:14 UTC, mahdi wrote:
How can we detect is `array` is static (fixed size) or 
dynamic, inside the function body?


`array` there is always dynamic because it is not of a fixed 
size type.


Why do you want to know though?


I thought we can simply denote `int[] x` in case we have an array 
argument in D functions. So according to your answer if a 
function expects a static array, it has to specify size of array 
in parameter declaration:


void diss(int[3] array) ...  //this expects a static array of 
size 3

void diss(int[] array) ...  //this expects a dynamic array

is this correct?

Re: tell if __traits(allMembers, ... ) is an enum (not manifest constant)

[Adam D. Ruppe via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 04:25:25 UTC, Nicholas Wilson 
wrote:

foreach(m; __traits(allMembers, ...)
{
static if(is(m== enum))
}



That's close but not quite there... try

static if(is(typeof(__traits(getMember, Item, m)) == enum))

for member variables, or if you are looking at a type itself 
youcan leave off the typeof() bit.

tell if __traits(allMembers, ... ) is an enum (not manifest constant)

[Nicholas Wilson via Digitalmars-d-learn]

there is no __traits(isEnum, ...)

I've tried
foreach(m; __traits(allMembers, ...)
{
static if (__traits(compiles,EnumMembers!(m)))
static if (EnumMembers!(m).length)
static if(is(m== enum))
}

I can detect static functions with __traits(isStaticFunction, ...)

Re: no size yet for forward reference error

[Erik Smith via Digitalmars-d]

Here's a better reduction of the problem.  Commenting out either 
of the lines marked HERE eliminates the error.   It's some kind 
of interaction with templates, RefCounted, and the cross 
referencing types.


erik


module database;
import std.typecons;

unittest {
auto con = Connection!int();
}

struct Connection(T) {
alias Statement = .Statement!T;   // HERE
}

struct Statement(T) {
alias Connection = .Connection!T;

private:

struct Payload {
Connection con;
this(Connection con_) {con = con_;}
}

alias RefCounted!(Payload, RefCountedAutoInitialize.no) Data;
Data data_;  // HERE
}

Re: Official compiler

[rsw0x via Digitalmars-d]

On Thursday, 25 February 2016 at 03:47:33 UTC, rsw0x wrote:
On Thursday, 25 February 2016 at 03:26:54 UTC, Adam D. Ruppe 
wrote:

On Thursday, 25 February 2016 at 03:16:57 UTC, rsw0x wrote:

licensing issues


I can't see any... Walter would be licensed to distribute all 
three.


GDC is under GPL


Oh, my bad I reread the post. I thought he meant combine them as 
in single frontend/three backends in a single executable.

Nevermind.

Re: Official compiler

[rsw0x via Digitalmars-d]

On Thursday, 25 February 2016 at 03:26:54 UTC, Adam D. Ruppe 
wrote:

On Thursday, 25 February 2016 at 03:16:57 UTC, rsw0x wrote:

licensing issues


I can't see any... Walter would be licensed to distribute all 
three.


GDC is under GPL

Re: Official compiler

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 25 February 2016 at 03:16:57 UTC, rsw0x wrote:

licensing issues


I can't see any... Walter would be licensed to distribute all 
three.

Re: Official compiler

[rsw0x via Digitalmars-d]

On Thursday, 25 February 2016 at 03:07:20 UTC, Puming wrote:
On Thursday, 25 February 2016 at 02:48:24 UTC, Walter Bright 
wrote:

[...]


Maybe in the future, when ldc/gdc catches up versions with dmd, 
we can combine them into a bundle for downloads? Then new 
people can just download the compiler bundle and run dmd or 
ldc/gdc as they like.


licensing issues

Re: Official compiler

[Puming via Digitalmars-d]

On Thursday, 25 February 2016 at 02:48:24 UTC, Walter Bright 
wrote:

On 2/24/2016 6:05 PM, Adam D. Ruppe wrote:
I've also heard from big users who want the performance more 
than compile time

and hit difficulty in build scaling..


I know that performance trumps all for many users. But we can 
have both - dmd and ldc/gdc.


My point is that compile speed is a valuable and distinguishing 
feature of D. It's one that I have to constantly maintain, or 
it bit rots away. It's one that people regularly dismiss as 
unimportant. Sometimes it seems I'm the only one working on the 
compiler who cares about it.


For comparison, C++ compiles like a pig, I've read that Rust 
compiles like a pig, and Go makes a lot of hay for compiling 
fast.


Maybe in the future, when ldc/gdc catches up versions with dmd, 
we can combine them into a bundle for downloads? Then new people 
can just download the compiler bundle and run dmd or ldc/gdc as 
they like.

Re: Official compiler

[Walter Bright via Digitalmars-d]

On 2/18/2016 9:52 AM, Kai Nacke wrote:

I really like the compiler diversity.


Me too. Having 3 major implementations is a great source of strength for D.

Re: Official compiler

[Walter Bright via Digitalmars-d]

On 2/18/2016 11:54 AM, David Nadlinger wrote:

But imagine that Walter
would have invested all the time he spent e.g. on implementing DWARF EH into
optimizing the LDC frontend/glue layer/backend pass structure instead. Who
knows, we might have an LDC-based compiler today that is faster than the DMD we
currently have.


A big chunk of that was getting D to catch C++ exceptions. And before I did this 
work, neither GDC nor LDC did, either. It's not a simple matter of just turning 
it on given Dwarf EH.


The point being, a lot of things are not going to happen for D unless I do them. 
Many of these require changing the front end, back end, and the runtime library 
in concert. It's a lot easier to make these work when the person working on it 
understands how all three work.


Once they're done, they provide a good guide on how to get it to work with a 
monumental code base like the gdc and ldc backends are.

Re: Official compiler

[Walter Bright via Digitalmars-d]

On 2/24/2016 6:05 PM, Adam D. Ruppe wrote:

I've also heard from big users who want the performance more than compile time
and hit difficulty in build scaling..


I know that performance trumps all for many users. But we can have both - dmd 
and ldc/gdc.


My point is that compile speed is a valuable and distinguishing feature of D. 
It's one that I have to constantly maintain, or it bit rots away. It's one that 
people regularly dismiss as unimportant. Sometimes it seems I'm the only one 
working on the compiler who cares about it.


For comparison, C++ compiles like a pig, I've read that Rust compiles like a 
pig, and Go makes a lot of hay for compiling fast.

Re: Official compiler

[Brian Schott via Digitalmars-d]

On Thursday, 25 February 2016 at 02:08:32 UTC, Paul O'Neil wrote:

On 02/18/2016 02:06 PM, rsw0x wrote:
I believe Brian Schott had worked on something like this for 
D... Did that ever go anywhere?


Brian's project is at https://github.com/Hackerpilot/generated .

I can't speak to the state of the project, but it hasn't been 
touched in about a year.


I built that to fuzz test parsers, not code generation or 
anything else. I can pretty much guarantee that its output should 
not compile.

Re: How to detect if an array if dynamic or static

[Adam D. Ruppe via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 01:31:17 UTC, Chris Wright wrote:

When you get to GC-allocated stuff, there's no way to tell.


The GC is easy, you can simply ask it:

http://dpldocs.info/experimental-docs/core.memory.GC.addrOf.1.html

"If p references memory not originally allocated by this garbage 
collector, if p is null, or if the garbage collector does not 
support this operation, null will be returned."



The append operator uses this kind of logic to determine if it is 
safe to append. The `capacity` property on slices can query, 
though it is zero in some cases where the GC owns it, but it 
still needs reallocation to be appended to (e.g. when the array 
is already at the max length of the allocated block, or when the 
stomping protection kicks in. See: 
http://dlang.org/d-array-article.html )

Re: Official compiler

[Paul O'Neil via Digitalmars-d]

On 02/18/2016 02:06 PM, rsw0x wrote:
> On Thursday, 18 February 2016 at 17:52:10 UTC, Kai Nacke wrote:
>> I really like the compiler diversity. What I miss (hint!) is a program
>> to verify the compiler/backend correctness. Just generate a random D
>> program, compile with all 3 compilers and compare the output. IMHO we
>> could find a lot of backend bugs this way. This would help all D
>> compilers.
>>
>> Regards,
>> Kai
> 
> reminds me of csmith
>  https://embed.cs.utah.edu/csmith/
> 
> I believe Brian Schott had worked on something like this for D... Did
> that ever go anywhere?

Brian's project is at https://github.com/Hackerpilot/generated .

I can't speak to the state of the project, but it hasn't been touched in
about a year.

-- 
Paul O'Neil
Github / IRC: todayman

Re: Official compiler

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 25 February 2016 at 01:53:51 UTC, Walter Bright 
wrote:
When I meet someone new who says they settled on D in their 
company for development, I casually ask why they selected D?


  "Because it compiles so fast."


I actually agree this is a big issue and one of the killer 
features to me.


But, I also need to point out that there's a selection bias going 
on here: of course D's users today like D's strengths today. If 
they didn't, they wouldn't be using it.


I've also heard from big users who want the performance more than 
compile time and hit difficulty in build scaling..

Re: DIP 84: Static Inheritance

[Iakh via Digitalmars-d]

On Friday, 30 October 2015 at 14:39:47 UTC, Atila Neves wrote:
From the discussion here: 
http://forum.dlang.org/post/tgnxocozkurfvmxqo...@forum.dlang.org, I thought a library solution would do to fix the issue of getting decent error messages when a type fails to satisfy a template constraint that it was meant to, such as `isInputRange`. So I submitted a PR (https://github.com/D-Programming-Language/phobos/pull/3677), it's been there ever since and doesn't seem like it'll go anywhere from the discussion (http://forum.dlang.org/post/qvofihzmappftdiwd...@forum.dlang.org).


So the only other way is a DIP (http://wiki.dlang.org/DIP84) 
for language and compiler support for static inheritance. It's 
backwards-compatible and IMHO worth looking at.


Please let me know what you think.

Atila


It could be better to extend UDA with checking and diagnostic 
functions


@IsInputRange
struct myRange {...

And some attrs not applicable for all things, extended UDA can 
handle it

Re: Official compiler

[Walter Bright via Digitalmars-d]

On 2/17/2016 4:35 PM, Chris Wright wrote:

And since DMD is
something like twice as fast as LDC, there's at least some argument in
favor of keeping it around.


When I meet someone new who says they settled on D in their company for 
development, I casually ask why they selected D?


  "Because it compiles so fast."

It's not a minor issue.

Re: How to detect if an array if dynamic or static

[Chris Wright via Digitalmars-d-learn]

On Wed, 24 Feb 2016 21:48:14 +, mahdi wrote:

> Suppose we have a function like this:
> 
> void diss(int[] array) ...
> 
> How can we detect is `array` is static (fixed size) or dynamic,
> inside the function body?

Static arrays point to memory on the stack, inside an aggregate type on 
the heap, or inside the static data area. In the stack case, you can use 
this strategy:

extern (C) void* thread_stackBottom();

bool isLocatedOnStack(T)(T[] arr) {
  int i;
  void* top = 
  auto bottom = thread_stackBottom();
  return arr.ptr >= min(top, bottom) && arr.ptr <= max(top, bottom);
}

When you get to GC-allocated stuff, there's no way to tell. Static data, 
I'm not sure.

This probably isn't what you want, though.

Re: Official compiler

[jmh530 via Digitalmars-d]

On Wednesday, 24 February 2016 at 22:43:07 UTC, Xavier Bigand 
wrote:


I know Visuald support ldc, but for dub I didn't find anything 
on how it find which compiler to use.


I agree the docs could be better. If you type dub build --help, 
it shows that --compiler is an option. So you would just pass 
--compiler=ldc2.

no size yet for forward reference error

[Erik Smith via Digitalmars-d]

In the process of converting my working database interface to be 
template based, I now get the following compiler error:


Error: struct 
std.database.mock.database.Statement!int.Statement.Payload no 
size yet for forward reference


I minimized the code to make it easier reason about.  It seems to 
have something to do with Payload, but it may also have something 
to do with the ResultRange / Row circular references.


The error is reported in object.d(2762,45).  This is DMD v2.070.

Any Ideas?


unittest {
auto db = Database!int.create();
auto con = Connection!int(db);
}

struct Database(T) {
static Database create() { return Database!T();}
}

struct Connection(T) {
alias Database = .Database!T;
alias Statement = .Statement!T;
}

struct Statement(T) {
alias Connection = .Connection!T;
alias Result = .Result;

private:

struct Payload {
Connection con;
this(Connection con_) {con = con_;}
this(this) { assert(false); }
void opAssign(Statement.Payload rhs) { assert(false); }
}

alias RefCounted!(Payload, RefCountedAutoInitialize.no) Data;
Data data_;
}

struct Result(T) {
alias Statement = .Statement!T;
alias ResultRange = .ResultRange!T;
alias Range = .ResultRange;
alias Row = .Row;

this(Statement stmt) {data_ = Data(stmt);}
ResultRange range() {return ResultRange(this);}
}

struct ResultRange(T) {
alias Result = .Result!T;
alias Row = .Row!T;
private Result result_;
this(Result result) {result_ = result;}
}


struct Row(T) {
alias Result = .Result!T;
this(Result* result) { result_ = result;}
private Result* result_;
}

Re: Simple performance question from a newcomer

[Ali Çehreli via Digitalmars-d-learn]

On 02/23/2016 12:12 PM, dextorious wrote:

> Some languages
> feature more accurate options separately, but never as the default, so
> it did not occur to me to specifically check the documentation for
> something like sum() (which is my fault, of course, no issues there).
> Having the more accurate pairwise summation algorithm in the standard
> library is certainly worthwhile for some applications, but I was a bit
> surprised to see it as the default.

According to Wikipedia, pairwise summation is the default algorithm in 
NumPy and Julia as well:


"Pairwise summation is the default summation algorithm in NumPy and the 
Julia technical-computing language".


  https://en.wikipedia.org/wiki/Pairwise_summation

Ali

Re: C++ UFCS update

[Timon Gehr via Digitalmars-d]

On 24.02.2016 23:10, Ola Fosheim Grøstad wrote:

On Wednesday, 24 February 2016 at 21:56:12 UTC, Timon Gehr wrote:

The ultimate validity of the premise does not matter for what I
objected to. You were trying to paint Walter's position internally
inconsistent in a very specific way that just does not hold water.


Sigh. I am not trying to paint anything, not even a bikeshed. I am
merely observing the following:

1. I've never had any issues related to "<<" for iostream.
...


Note that I am not the one complaining about overloaded tokens.


2. I am rather annoyed by the inconsistent use of symbols in D.
...


It's not inconsistent. It's overloading at the lexical level that gets 
resolved at the level of the grammar.



3. Objecting to "<<" for iostream while using symbols incosistently
yourself IS ironic.


What is and isn't ironic, isn't a matter of «validity of the premise».


You misunderstand what that part of the sentence refers to. (It's what I 
quoted.)



It is a matter of interpretation. Not your interpretation. Mine.
...


You might want to keep those aspects to yourself or express their 
subjectivity more explicitly if you don't want them to be mistaken for a 
point being made that resembles points being made using the same wording.



Also, the usability issues concerning symbols isn't related to
mathematical definitions, but is related to the mnemonics of the
symbols, or the interpretation of them, by a human being. Not by a machine.

As such a useful mnemonic for "<<" is that it is for moving stuff to the
left. Which could work equally well for a stream as it does for bits.

There is no apparent overlap between the mnemonics for "!" in the
context of templates or bools. Same with "~", which in the context of C
means "flip the bits",


In the context of C, "*" means either "dereference" or "multiply". "&" 
means either "take address" or "bitwise and".



with the wave being a mnemonic for flipping.
...


Uh...


I find it ironic that iostream is more consistent with the mnemonics of
the symbols than D is. Deal with it.  Don't defend it. Fix it.



I'm afraid I personally don't care too much about any of that.

Also, I'm not defending anything. I was attacking annoying rhetoric.
Not anymore though. I'm done here.

[Issue 15711] Incorrect type inferring of [char]/string when passed via recursive template, extracting it from a structure field

[via Digitalmars-d-bugs]

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

Alexander Tumin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--

[Issue 15711] Incorrect type inferring of [char]/string when passed via recursive template, extracting it from a structure field

[via Digitalmars-d-bugs]

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

--- Comment #2 from Alexander Tumin  ---
According to cast table from https://dlang.org/spec/const3.html this is not bug
at all and should be the defined behavior; const(char)[], what ['z'] is, cannot
be implicitly converted to immutable(char)[], which what the string is.

The solution to this case is simply wrap ['z'] into cast(string)(['z']) and all
should work just fine. I'm sorry, this should be closed as not a bug.

--

Re: Official compiler

[Xavier Bigand via Digitalmars-d]

Le 17/02/2016 23:57, Márcio Martins a écrit :

I was reading the other thread "Speed kills" and was wondering if there
is any practical reason why DMD is the official compiler?

Currently, newcomers come expecting their algorithm from rosetta code to
run faster in D than their current language, but then it seems like it's
actually slower. What gives?

Very often the typical answer from this community is generally "did you
use LDC/GDC?".

Wouldn't it be a better newcomer experience if the official compiler was
either LDC or GDC?
For us current users it really doesn't matter what is labelled official,
we pick what serves us best, but for a newcomer, the word official
surely carries a lot of weight, doesn't it?

 From a marketing point of view, is it better for D as a language that
first-timers try the bleeding-edge, latest language features with DMD,
or that their expectations of efficient native code are not broken?

Apologies if this has been discussed before...


Like you said it's only a marketing issue.

DMD will and can stay the reference, but IMO as you also evoke it the 
most important thing is certainly to have LDC/GDC more sync with DMD 
front-end version because new comers will feel comfortable to use an 
other compiler up to date that can also target more platforms.


I am exactly in this case, I prefer to use a compiler that make my code 
running on all platforms (android, iOS,...), but I don't want suffering 
of staying on an older front-end that will limit me by missing features 
or bugs.

So I am using DMD with some frustration lol.

And ldc/gdc need more love :
1. A direct link to download latest version (instead of a like to the 
project page)

2. An installer like for DMD that can download Visuald optionally
3. Be auto detected by building tools (dub, Visuald,...)

I know Visuald support ldc, but for dub I didn't find anything on how it 
find which compiler to use.

Re: How to detect if an array if dynamic or static

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 21:48:14 UTC, mahdi wrote:
How can we detect is `array` is static (fixed size) or dynamic, 
inside the function body?


`array` there is always dynamic because it is not of a fixed size 
type.


Why do you want to know though?

Re: Installing DUB on OSX

[Joel via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 15:16:17 UTC, Jacob Carlborg 
wrote:

On 2016-02-24 09:09, Joel wrote:


I have OS X version 10.11.3

What about adding another path to $PATH? I don't know how 
though.


Open or create ~/.bash_profile. Add the following:

export PATH=:$PATH

Replace  with the path you want to add. Close and 
save the file. Open a new window/tab in the Terminal for the 
change to take affect.



I get this with DUB:

Joels-MacBook-Pro:DGuy joelcnz$ dub --force
Performing "debug" build using dmd for x86_64.
Build directory
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-353A83191ABC652C7DFA10932343301C/
is not writable. Falling back to direct build in the system's 
temp folder.

dsfml:system 2.1.0: building configuration "library"...
Build directory
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-265846E0F1E3C7406127D9762F1360F9/
is not writable. Falling back to direct build in the system's 
temp folder.

dsfml:audio 2.1.0: building configuration "library"...
Build directory
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-D924A3C3A5A575D51B048A1FD5A04C95/
is not writable. Falling back to direct build in the system's 
temp folder.

dsfml:window 2.1.0: building configuration "library"...
Build directory
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-68F7517C342E684747C39849DE501687/
is not writable. Falling back to direct build in the system's 
temp folder.

dsfml:graphics 2.1.0: building configuration "library"...
Build directory
.dub/build/application-debug-posix.osx-x86_64-dmd_2070-2EBE4466CF46539CC1D524962E530835/
is not writable. Falling back to direct build in the system's 
temp folder.

jex ~master: building configuration "application"...
Linking...
2016-02-24 21:06:38.614 xcodebuild[1076:208774] [MT] 
PluginLoading:

Skipping plug-in at path '/Library/Application
Support/Developer/Shared/Xcode/Plug-ins/D for Xcode.xcplugin' 
because it

is not compatible with this version of Xcode.
2016-02-24 21:06:40.157 xcodebuild[1079:208795] [MT] 
PluginLoading:

Skipping plug-in at path '/Library/Application
Support/Developer/Shared/Xcode/Plug-ins/D for Xcode.xcplugin' 
because it

is not compatible with this version of Xcode.
ld: can't write output file: jex for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v 
to see

invocation)
--- errorlevel 1
dmd failed with exit code 1.
Joels-MacBook-Pro:DGuy joelcnz$


Run "dub build --force --verbose" to see command it uses for 
linking. Run that command manually and append "-L-v" (without 
quotes) to see the verbose output from the linker.


I added a new path ($PATH):

Joels-MacBook-Pro:DGuy joelcnz$ which dub
/Users/joelcnz/jpro/bin/dub
Joels-MacBook-Pro:DGuy joelcnz$

I get this:

Joels-MacBook-Pro:DGuy joelcnz$ dmd -lib 
-of../../../.dub/packages/dsfml-2.1.0/libdsfml_system.a -debug -g 
-w -version=Have_dsfml_system 
-I../../../.dub/packages/dsfml-2.1.0/src/ 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/clock.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/config.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/err.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/inputstream.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/lock.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/mutex.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/package.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/sleep.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/string.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/thread.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/time.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/vector2.d 
../../../.dub/packages/dsfml-2.1.0/src/dsfml/system/vector3.d 
-vcolumns -L-v
Error: Error writing file 
'../../../.dub/packages/dsfml-2.1.0/libdsfml_system.a'

Joels-MacBook-Pro:DGuy joelcnz$

Re: C++ UFCS update

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 24 February 2016 at 21:56:12 UTC, Timon Gehr wrote:
The ultimate validity of the premise does not matter for what I 
objected to. You were trying to paint Walter's position 
internally inconsistent in a very specific way that just does 
not hold water.


Sigh. I am not trying to paint anything, not even a bikeshed. I 
am merely observing the following:


1. I've never had any issues related to "<<" for iostream.

2. I am rather annoyed by the inconsistent use of symbols in D.

3. Objecting to "<<" for iostream while using symbols 
incosistently yourself IS ironic.



What is and isn't ironic, isn't a matter of «validity of the 
premise». It is a matter of interpretation. Not your 
interpretation. Mine.


Also, the usability issues concerning symbols isn't related to 
mathematical definitions, but is related to the mnemonics of the 
symbols, or the interpretation of them, by a human being. Not by 
a machine.


As such a useful mnemonic for "<<" is that it is for moving stuff 
to the left. Which could work equally well for a stream as it 
does for bits.


There is no apparent overlap between the mnemonics for "!" in the 
context of templates or bools. Same with "~", which in the 
context of C means "flip the bits", with the wave being a 
mnemonic for flipping.


I find it ironic that iostream is more consistent with the 
mnemonics of the symbols than D is. Deal with it. Don't defend 
it. Fix it.

Re: Unum II announcement

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 24 February 2016 at 21:37:44 UTC, Nick B wrote:
On Wednesday, 24 February 2016 at 21:07:01 UTC, Ola Fosheim 
Grøstad wrote:




Implement unum-computing as GPU-compute-shaders. They are 
present in OpenGL ES 3.1, so they will become ubiquitous.


Are you sure ?
Here is a link to the spec (pdf, 505 pages) and I can find no 
mention of unums ?


Sorry, I meant that  GPU-compute-shaders will be present in 
OpenGL ES 3.1, which would make OpenGL ES 3.1 a potentially very 
useful target for an unum implementation. From chapter 17:


«In addition to graphics-oriented shading operations such as 
vertex and fragment
shading, generic computation may be performed by the GL through 
the use of
compute shaders. The compute pipeline is a form of single-stage 
machine that runs

generic shaders.»

So, that means that _if_ one can do Unum efficiently using 
compute-shaders then one can have efficient Unum support on all 
platforms (eventually). That would make it a valid language 
target IMO.

Re: C++ UFCS update

[Timon Gehr via Digitalmars-d]

On 24.02.2016 22:31, Ola Fosheim Grøstad wrote:

That just a very convenient rewriting of reality,


The ultimate validity of the premise does not matter for what I objected 
to. You were trying to paint Walter's position internally inconsistent 
in a very specific way that just does not hold water.

How to detect if an array if dynamic or static

[mahdi via Digitalmars-d-learn]

Suppose we have a function like this:

void diss(int[] array) ...

How can we detect is `array` is static (fixed size) or dynamic, 
inside the function body?

Re: Unum II announcement

[Nick B via Digitalmars-d]

On Wednesday, 24 February 2016 at 21:14:46 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 24 February 2016 at 20:59:20 UTC, Timon Gehr 
wrote:




The basic idea for Unums seems that you get an estimate of the 
bounds and then recompute using higher precision or better 
algorithm when necessary.


Agreed. This seems to be my understanding as well.

Nick

Re: Unum II announcement

[Nick B via Digitalmars-d]

On Wednesday, 24 February 2016 at 20:11:39 UTC, Robbert van Dalen 
wrote:
Sorry to hijack this thread, but I think unum II is the best 
thing since sliced bread!


:)


It would be great if Dr. Gustafson would initiate a google 
group so we can discuss the inner workings of unum II. If not, 
I guess I will start one :)


Where do you suggest that such a group hang out ?

Robert, what is your background ?

I have asked Dr. Gustafson how he would like to respond to some 
of the questions raised on this forum.


Nick

Re: Unum II announcement

[Nick B via Digitalmars-d]

On Wednesday, 24 February 2016 at 21:07:01 UTC, Ola Fosheim 
Grøstad wrote:




Implement unum-computing as GPU-compute-shaders. They are 
present in OpenGL ES 3.1, so they will become ubiquitous.


Are you sure ?
Here is a link to the spec (pdf, 505 pages) and I can find no 
mention of unums ?


https://www.khronos.org/registry/gles/specs/3.1/es_spec_3.1.pdf


Nick

Re: C++ UFCS update

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 24 February 2016 at 21:12:23 UTC, Timon Gehr wrote:
It's obvious that Walter considers arity to be part of the 
identity of an operator. If you find pleasure in finding irony 
in misrepresented statements, feel free. I don't.


There's nothing misrepresented in what I wrote. If you want arity 
to be part of the identity, you might as well including typing. 
That just a very convenient rewriting of reality, typical 
apologetic D-advocacy. The operator is the symbol and reusing it 
for something unrelated has a negative effect on usability.


You guys need to stop complaining about the insignificant 
splinters of C++ and start worrying about the beams that are 
stumbling blocks for D. C++ is alive and kicking...

Re: Swift deprecate i++ and c-style for loop

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 24 February 2016 at 21:03:12 UTC, rsw0x wrote:
Could you expand upon what you mean here? I have an entire D 
project not using the GC and make use of slices everywhere.


Then you need ownership of arrays, not just slices. You can of 
course use slices to represent non-ownership. In C++ you could 
use std::vector + gsl::span. Just using gsl::span or D's slices 
everywhere is a very bad idea.

Re: Swift deprecate i++ and c-style for loop

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 24 February 2016 at 21:03:12 UTC, rsw0x wrote:
On Wednesday, 24 February 2016 at 20:47:50 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 24 February 2016 at 18:06:19 UTC, Steven 
Schveighoffer wrote:
I'm quite glad D stuck with the same type for arrays and 
array slices.


And how will you get around this when not having a GC?


Could you expand upon what you mean here? I have an entire D 
project not using the GC and make use of slices everywhere.


Slicing non-GC memory so that you get dynamic arrays is fine, but 
then you have to have somewhere else managing that memory, 
whereas you don't really have to worry about it when using the 
GC, and you have to avoid array operations which would use the GC 
(appending or concatenation). So, having code that doesn't use 
the GC but does use dynamic array treat dynamic arrays the same 
way that a program that uses the GC would treat them can become 
problematic - particularly since it's trivial to have dynamic 
arrays floating around referring to some chunk of malloced memory 
without realizing that they're still around when you free that 
malloced memory.


So, yes. D's dynamic arrays work without the GC (barring the few 
operations that require the GC), but they're designed with the GC 
in mind and don't manage their own memory, meaning that you 
almost certainly need to treat them a bit differently when you 
don't have the GC (certainly, you have to be a lot more careful 
about what code you let hold onto dynamic arrays in order to 
avoid having them exist after the memory they refer to has been 
freed).


But doing stuff like feeding dynamic arrays which are slices of 
malloced memory to a bunch of functions that just process them 
and give you a result without holding onto them or attempting to 
append to them should work just fine. It's the stuff that might 
hold onto them where things get hairy.


- Jonathan M Davis

Re: Unum II announcement

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 24 February 2016 at 20:59:20 UTC, Timon Gehr wrote:
Unums represent either single numbers or entire segments and 
those segments are not closed under the arithmetic operations, 
so without a efficient representation for sets, Unums are not 
useful as a more rigorous replacement for floating point 
numbers.


I don't know if Unums are more useful than interval arithmetics, 
but without the 2008 edition of IEEE754 you cannot even represent 
interval arithmetics using floats AFAIK!


The basic idea for Unums seems that you get an estimate of the 
bounds and then recompute using higher precision or better 
algorithm when necessary. With regular floats you just get a 
noisy value and you need much more heavy machinery to know 
whether you need to recompute using a better algorithm/higher 
precision.

Re: C++ UFCS update

[Timon Gehr via Digitalmars-d]

On 24.02.2016 11:24, Ola Fosheim Grøstad wrote:

On Tuesday, 23 February 2016 at 20:49:40 UTC, Timon Gehr wrote:

On 23.02.2016 21:35, Ola Fosheim Grøstad wrote:

I find it ironic that Walter objects to reusing operators such as "<<"
while he is reusing "!" for templates


No reusing and no irony here. "!" for template instantiation is a
binary usage.


Wrong.  Unary, postfix, prefix, mixfix does not matter. It still affects
usability.

Definition for "operator":

«a symbol or function denoting an operation (e.g. ×, +).»



I was responding to a very specific statement, namely the one I quoted, 
if that was unclear.


It's obvious that Walter considers arity to be part of the identity of 
an operator. If you find pleasure in finding irony in misrepresented 
statements, feel free. I don't.

Re: Unum II announcement

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 23 February 2016 at 21:47:10 UTC, H. S. Teoh wrote:
relatively easy to transition it into a built-in type.  I don't 
see this happening for at least another 5-10, though.  It took 
at least as long (probably longer) for hardware manufacturers 
to adopt the IEEE standard, and right now unums aren't even 
standardized yet.


Implement unum-computing as GPU-compute-shaders. They are present 
in OpenGL ES 3.1, so they will become ubiquitous.

Re: Swift deprecate i++ and c-style for loop

[rsw0x via Digitalmars-d]

On Wednesday, 24 February 2016 at 20:47:50 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 24 February 2016 at 18:06:19 UTC, Steven 
Schveighoffer wrote:
I'm quite glad D stuck with the same type for arrays and array 
slices.


And how will you get around this when not having a GC?


Could you expand upon what you mean here? I have an entire D 
project not using the GC and make use of slices everywhere.

Re: Unum II announcement

[Timon Gehr via Digitalmars-d]

On 24.02.2016 00:52, Nicholas Wilson wrote:

On Tuesday, 23 February 2016 at 20:22:19 UTC, jmh530 wrote:

On Monday, 22 February 2016 at 05:08:13 UTC, Nick B wrote:


I strongly recommend that you download the presentation [Powerpoint,
35 pages] as there are lots of Notes with the presentation.



I had a chance to go through the presentation a bit.

The part about SORNs is a little confusing. For instance, suppose I
divide 0 by 0 using unums. What would be internally represented? I
assume that it has to be the SORN because it is encompasses all the
unums plus arbitrary ranges of unums.


0 I think. 0/0 == 0*(/0)==0*inf and then the set of numbers
that represents that is the empty set == 0 (i think)



The result should be everything. a/b is a number c such that a = b·c. If 
a and b are 0, c is arbitrary.




For instance, the 0's could be represented by 00 in the 2bit unum on
page 3. But alternately, they could be expressed as 0010 in the SORN
calculation. However, the result should be the SORN  from page 7
because the unum is undefined.

In my head, I imagine the process would be something like, I type
unum x = 0;
this creates a SORN variable equal to 0010 in bits.

I then divide
auto y = x / x;
Behind the scenes, it will do the table lookup and give y as the SORN
representing  in bits.

If instead of the above for y, it does
auto z = x / 1
where 1 is a unum literal, then it will get the unum value of the SORN
in each case and do the appropriate operation as unums, get the unum
result, then convert that to a SORN result.

Does this make sense?


There is no conversion to a sorn result. think of unum is to sorn
what a pointer is to an address space: a unum is a "location" in that set.
a mapping of n bits to 2^n possible representations.
(my understanding)



Unums represent either single numbers or entire segments and those 
segments are not closed under the arithmetic operations, so without a 
efficient representation for sets, Unums are not useful as a more 
rigorous replacement for floating point numbers.


The suggested tables for the arithmetic operations seem to map two Unums 
to one 16 bit SORN. (See slide 27 and 30 if in doubt.)

Re: Swift deprecate i++ and c-style for loop

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 24 February 2016 at 18:06:19 UTC, Steven 
Schveighoffer wrote:
I'm quite glad D stuck with the same type for arrays and array 
slices.


And how will you get around this when not having a GC?

Re: Simple performance question from a newcomer

[jmh530 via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 19:15:23 UTC, dextorious wrote:


However, there doesn't seem to be any way to specify different 
dflags for different compilers


There are examples like in the package format page
"dflags-dmd": ["-vtls"],
"sourceFiles-windows-x86_64-dmd": ["lib/win32/mylib.lib"],
that would give some idea of how to do it.

Combining them together, you are able to do things like
"dflags-windows-x86_64-dmd": ["-vtls"],

So yes, it is do-able, but as you mention above, the docs page 
could use some work in making this functionality clear.

Re: Head Const

[rsw0x via Digitalmars-d]

On Wednesday, 24 February 2016 at 19:28:28 UTC, extrawurst wrote:
On Wednesday, 24 February 2016 at 09:57:51 UTC, Atila Neves 
wrote:
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright 
wrote:

[...]


I think that increasing language complexity for the sake of 
C++ integration is a dubious trade-off, especially since "all" 
that's required is correct name mangling. There's no guarantee 
of what the C++ side can do with any type of constness anyway, 
I'd say that any "extern(C++)" mangles as C++ would and leave 
it at that.


Atila


I agree with that concern. I would rather see the effort being 
used to improve D - e.g support for GC-free code than to help 
us integrate the complexity of C++ that D was intended to get 
rid of.


--Stephan


A usable `shared` would even be nice.

Re: Unum II announcement

[Robbert van Dalen via Digitalmars-d]

Sorry to hijack this thread, but I think unum II is the best 
thing since sliced bread!


Note that, next to a D implementation, there are already unum I 
implementations in both Julia, Python (and Pony?).


I believe it would be nice to have a discussion on unum II that 
is indifferent to implementations. Currently, I haven't found any 
discussion or forum on the web that's related to unum (I or II).


It would be great if Dr. Gustafson would initiate a google group 
so we can discuss the inner workings of unum II. If not, I guess 
I will start one :)


cheers,
Robbert.

Re: Head Const

[extrawurst via Digitalmars-d]

On Wednesday, 24 February 2016 at 09:57:51 UTC, Atila Neves wrote:
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright 
wrote:

rears its head again :-)

Head Const is what C++ has for const, i.e. it is not 
transitive, applies to one level only. D has transitive const.


What head const will do for us:

1. make it easy to interface to C++ code that uses const, as 
currently it is not very practical to do so, you have to 
resort to pragma(mangle)


2. supports single assignment style of programming, even if 
the data is otherwise mutable


The downside is, of course, language complexity.


I think that increasing language complexity for the sake of C++ 
integration is a dubious trade-off, especially since "all" 
that's required is correct name mangling. There's no guarantee 
of what the C++ side can do with any type of constness anyway, 
I'd say that any "extern(C++)" mangles as C++ would and leave 
it at that.


Atila


I agree with that concern. I would rather see the effort being 
used to improve D - e.g support for GC-free code than to help us 
integrate the complexity of C++ that D was intended to get rid of.


--Stephan

Re: Simple performance question from a newcomer

[dextorious via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 03:33:14 UTC, Mike Parker wrote:

On Tuesday, 23 February 2016 at 20:03:30 UTC, dextorious wrote:
For instance, I am still not sure how to make it pass the -O5 
switch to the LDC2 compiler and the impression I got from the 
documentation is that explicit manual switches can only be 
supplied for the DMD compiler.


If you're referring to this:

"Additional flags passed to the D compiler - note that these 
flags are usually specific to the compiler in use, but a set of 
flags is automatically translated from DMD to the selected 
compiler"


My take is that a specific set of flags are automatically 
translated (so you don't need to make a separate dflags entry 
for each compiler you support if you only use those flags), but 
you can pass any compiler-specific flags you need.


There's part of what I'm referring to, yes. There doesn't seem to 
be any documentation on what gets translated and what doesn't.


For the moment, the only way I've found to manually pass specific 
compiler options ("-O5 -singleobj" in my case) is by settings the 
dflags attribute when defining a buildType. However, there 
doesn't seem to be any way to specify different dflags for 
different compilers, so I am forced to introduce separately named 
buildTypes for each compiler. Since I still need to manually 
specify the compiler using the --compiler option when running 
dub, this feels like I'm using a hacky workaround rather than a 
consistently designed CLI. Furthermore, from the documentation, I 
have no idea if what I'm doing is the intended way or just an 
ugly hack around whatever piece of information I've missed.

Re: std.xml2 (collecting features)

[Craig Dillabaugh via Digitalmars-d]

On Tuesday, 23 February 2016 at 12:46:38 UTC, Dmitry wrote:

On Tuesday, 23 February 2016 at 11:22:23 UTC, Joakim wrote:
Then write a good XML extraction-only library and dub it. I 
see no reason to include this in Phobos

You won't be able to sleep if it will be in Phobos?

I use XML and I don't like check tons of side libraries for see 
which will be good for me, which have support (bugfixes), which 
will have support in some years, etc.
Lot of systems already using XML and any serious language 
_must_ have official support for it.


So are you trying to say C/C++ are not serious languages :o)

Having said that, as much as I hate XML, basic support would be a 
nice feature for the language.

[Issue 15720] New: iota(long.max, long.min, step) does not work properly

[via Digitalmars-d-bugs]

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

  Issue ID: 15720
   Summary: iota(long.max, long.min, step) does not work properly
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
--
import std.range;
import std.stdio;
void main() {
writeln(iota(long.max, long.min, -1).length);
writeln(iota(long.max, long.min, -2).length);
writeln(iota(long.max, long.min, -3).length);
}
--

Output:
--
18446744073709551615
0
1
--

Expected output:
--
18446744073709551615
9223372036854775807
6148914691236517205
--

--

Re: Swift deprecate i++ and c-style for loop

[Steven Schveighoffer via Digitalmars-d]

On 2/24/16 11:40 AM, Meta wrote:

On Wednesday, 24 February 2016 at 16:37:04 UTC, Suliman wrote:

https://github.com/apple/swift/blob/master/CHANGELOG.md

func slices() {
var array = ["First", "Second", "Third", "Fourth"]
array.removeLast()
array.removeFirst()
}

also look very intuitive. I looked at std.algorithm.mutation and did
not find anything for this. I see only simple remove option.


The D equivalent is this:

array = array[0..$ - 1];
array = array[1..$];

Arguably just as intuitive.


I think there is a difference -- Swift arrays are not slices, so Array 
is not the same type as ArraySlice.


I believe Array.removeFirst is O(n). I think it also returns the element 
removed.


I also believe that it will affect any slices of the array, unlike D code.

Swift also has Array.dropFirst(n), which does what the D slice does (and 
returns an ArraySlice). Arrays also support slicing like D does, though 
with different index range notation.


Not 100% sure, the docs are not super clear on this.

I'm quite glad D stuck with the same type for arrays and array slices.

-Steve

Re: Dynamic pitch shift

[Guillaume Piolat via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 14:02:49 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 24 February 2016 at 10:33:56 UTC, Tanel Tagaväli 
wrote:

Hello!

I've been making some progress on the native D audio front:
https://github.com/clinei/daud/tree/28ac042a16ae6785605a9a501b5f867c8f962055

It's a continuous waveform generator, currently outputting a 
saw wave that changes pitch every 1K frames.


Generating a saw waveform for an LFO is the same as generating 
the phase, which is easy to do with using D's modular integers. 
Just add the delta and let it wrap.


If you are generating it for a VCO then you need a bandlimited 
oscilator:


https://ccrma.stanford.edu/~juhan/vas.html

(Abrupt changes in pitch will cause a discontinuity in the 
second derived which is audible, so you might want to 
interpolate.)


dplug:dsp has mipmapped oscillators
https://github.com/p0nce/dplug/blob/master/dsp/dplug/dsp/wavetable.d

Though it isn't fantastic aliasing-wise on the last octave, I 
should try something than power-of-2s next time I need it.

Re: Curl HTTP segfault

[Kagamin via Digitalmars-d-learn]

Oops, no, looks like you can't put HTTP in a class, because it 
works with GC and is ref counted.

Re: Curl HTTP segfault

[Kagamin via Digitalmars-d-learn]

http://pastebin.com/JfPtGTD8 ?

Re: Swift deprecate i++ and c-style for loop

[David Nadlinger via Digitalmars-d]

On Wednesday, 24 February 2016 at 16:37:04 UTC, Suliman wrote:

func slices() {
var array = ["First", "Second", "Third", "Fourth"]
array.removeLast()
array.removeFirst()
}

also look very intuitive.


Have a look at http://dlang.org/phobos/std_range.html#dropOne.

 — David

Re: Swift deprecate i++ and c-style for loop

[Meta via Digitalmars-d]

On Wednesday, 24 February 2016 at 16:37:04 UTC, Suliman wrote:

https://github.com/apple/swift/blob/master/CHANGELOG.md

func slices() {
var array = ["First", "Second", "Third", "Fourth"]
array.removeLast()
array.removeFirst()
}

also look very intuitive. I looked at std.algorithm.mutation 
and did not find anything for this. I see only simple remove 
option.


The D equivalent is this:

array = array[0..$ - 1];
array = array[1..$];

Arguably just as intuitive.

Swift deprecate i++ and c-style for loop

[Suliman via Digitalmars-d]

https://github.com/apple/swift/blob/master/CHANGELOG.md

func slices() {
var array = ["First", "Second", "Third", "Fourth"]
array.removeLast()
array.removeFirst()
}

also look very intuitive. I looked at std.algorithm.mutation and 
did not find anything for this. I see only simple remove option.

Re: Using DList with capacity constraint (aka circular buffer)?

[Steven Schveighoffer via Digitalmars-d]

On 2/24/16 9:46 AM, Seb wrote:

Hey all,

this is yet another post about phobos (missing) data structures ;-)
I know this has been discussed quite a bit - [1,2,3] to name a few.

While it would be nice to have those "trivially to implement" wrappers
for some common use cases (map, unordered map, set, multiset, ...) [1],
this question focuses solely on dequeues.


FYI, dcollections has a deque that is based on 2 arrays:

https://github.com/schveiguy/dcollections/blob/master/dcollections/Deque.d

-Steve

Curl HTTP segfault

[skilion via Digitalmars-d-learn]

Hello everyone,
I have had this problem for a little while but I don't understand 
if I'm am not using correctly the HTTP struct, or if it is a 
library bug.


Hear is my code: http://pastebin.com/Pgx7bqum

I get a segfault on exit in the destructor calling 
std.net.curl.Curl.shutdown()


Workarounds that I found are :
- call http.shutdown() before the end of main
- make http static

Re: Using DList with capacity constraint (aka circular buffer)?

[bitwise via Digitalmars-d]

On Wednesday, 24 February 2016 at 14:46:12 UTC, Seb wrote:

Hey all,

this is yet another post about phobos (missing) data structures 
;-)
I know this has been discussed quite a bit - [1,2,3] to name a 
few.


While it would be nice to have those "trivially to implement" 
wrappers for some common use cases (map, unordered map, set, 
multiset, ...) [1], this question focuses solely on dequeues.


It is great that we have DList, so having a circular buffer 
(aka constrained queue) should be easy.


I do understand that baking this into DList  (as e.g. Python 
does) might (a) make things more complex or (b) add overhead 
that isn't needed for every user.


However my question is: why is there not a neat wrapper around 
DList with a capacity constraint?


Unfortunately we don't have inheritance for structs, but 
proxying most methods should work too (see e.g [4]).


1) Has anyone else missed deque with capacity constraints?
2) Would such a wrapper fit into phobos?
3) Would you prefer (a) a wrapper around DList [4], (b) around 
arrays [5] or (c) a "vanilla" circular queue?

(b is slower, but allows indexing)

Best wishes,

[1] 
https://stackoverflow.com/questions/7162274/why-is-d-missing-container-classes
[2] 
http://forum.dlang.org/thread/mailman.852.1359488662.22503.digitalmar...@puremagic.com
[3] 
http://forum.dlang.org/post/mailman.394.1358112013.22503.digitalmar...@puremagic.com

[4] http://dpaste.dzfl.pl/d8de9325e9a3
[5] http://rosettacode.org/wiki/Queue/Usage#Faster_Version


Andrei is working on containers, but struggling with trying to 
make them @safe without comprimising efficiency or utility, 
AFAIK. Getting the containers done to his liking may require the 
work on lifetimes(language supported ref counting) to be 
complete. IIRC, there was a circular buffer on code.dlang.org 
somewhere. I've been planning on adding one to my container 
set(not on code.dlang.org yet) which would be implemented on a 
contiguous array, with the contents wrapping around as items are 
added/removed. I believe it's the most efficient approach.


   Bit

Re: vk.xml

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/23/16 10:42 PM, Mike Parker wrote:

On Wednesday, 24 February 2016 at 00:50:40 UTC, Nicholas Wilson wrote:


AA's are nice in theory but the non-deterministic nature of their
order of iteration is painful...


An ordered map as the default AA implementation would be worse. Most use
cases for a hash map don't need ordering. Perhaps we'll have one in
std.container at some point, but as it stands I'm unaware of any
implementations out there. Neither the EMSI containers [1] nor
dcollections [2] has one that I can see.

[1]
https://github.com/economicmodeling/containers/tree/master/src/containers
[2] https://github.com/schveiguy/dcollections/tree/master/dcollections


I've contemplated adding one. I think it's a nice feature of php.

But note that red black trees are ordered if you need some sort of 
ordering independent of insertion order.


-Steve

Re: C++ UFCS update

[jmh530 via Digitalmars-d]

On Wednesday, 24 February 2016 at 10:03:19 UTC, Ola Fosheim 
Grøstad wrote:


if(!a!(c,!d)(!e)){...}


Working through this,
!a, !d, and !e are unary operators
a!(x)(y) is the only template

Looks messy, but really isn't that hard to figure out.

I don't think !d makes sense as a template argument (unary not 
something usually doesn't produce a type). If you want it even 
easier to understand, how about:


alias acd = a!(c, d);
if(!(acd(!e)))


a~=3;
b=~3;


I agree that this is confusing. Only thing I would recommend is 
formatting and maybe adding parenthesis.


a ~= 3;
b = (~3);

[Issue 11176] array.ptr in @safe code

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #10 from Steven Schveighoffer  ---
(In reply to Kenji Hara from comment #9)
> One another way I can think is, array.ptr property would add a hidden check
> `arr.length != 0` under @safe code, then returns `null` instead when the
> length is 0.

As someone who lives in the camp of "empty arrays and null arrays should be
treated the same", I think this behavior wouldn't affect me.

However, many significant people depend on this NOT being the case. Think of
the pushback for the if(!arr) fix.

To make the behavior different if you add a @safe tag may not affect them, but
since the compiler can *infer* safety, this will be bad for anyone. Imagine you
have template code not marked @safe, and you find a legitimate use for arr[$ ..
$].ptr. The compiler may infer @safe, and then your code fails at runtime even
though it would pass if not inferred @safe.

In order to avoid such an issue, I think you have to just disallow ptr access
in @safe code. That's the only thing that's checkable at compile-time, and will
prevent a @safe inference.

--

Re: Installing DUB on OSX

[Jacob Carlborg via Digitalmars-d-learn]

On 2016-02-24 09:09, Joel wrote:


I have OS X version 10.11.3

What about adding another path to $PATH? I don't know how though.


Open or create ~/.bash_profile. Add the following:

export PATH=:$PATH

Replace  with the path you want to add. Close and save the 
file. Open a new window/tab in the Terminal for the change to take affect.



I get this with DUB:

Joels-MacBook-Pro:DGuy joelcnz$ dub --force
Performing "debug" build using dmd for x86_64.
Build directory
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-353A83191ABC652C7DFA10932343301C/
is not writable. Falling back to direct build in the system's temp folder.
dsfml:system 2.1.0: building configuration "library"...
Build directory
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-265846E0F1E3C7406127D9762F1360F9/
is not writable. Falling back to direct build in the system's temp folder.
dsfml:audio 2.1.0: building configuration "library"...
Build directory
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-D924A3C3A5A575D51B048A1FD5A04C95/
is not writable. Falling back to direct build in the system's temp folder.
dsfml:window 2.1.0: building configuration "library"...
Build directory
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-68F7517C342E684747C39849DE501687/
is not writable. Falling back to direct build in the system's temp folder.
dsfml:graphics 2.1.0: building configuration "library"...
Build directory
.dub/build/application-debug-posix.osx-x86_64-dmd_2070-2EBE4466CF46539CC1D524962E530835/
is not writable. Falling back to direct build in the system's temp folder.
jex ~master: building configuration "application"...
Linking...
2016-02-24 21:06:38.614 xcodebuild[1076:208774] [MT] PluginLoading:
Skipping plug-in at path '/Library/Application
Support/Developer/Shared/Xcode/Plug-ins/D for Xcode.xcplugin' because it
is not compatible with this version of Xcode.
2016-02-24 21:06:40.157 xcodebuild[1079:208795] [MT] PluginLoading:
Skipping plug-in at path '/Library/Application
Support/Developer/Shared/Xcode/Plug-ins/D for Xcode.xcplugin' because it
is not compatible with this version of Xcode.
ld: can't write output file: jex for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
--- errorlevel 1
dmd failed with exit code 1.
Joels-MacBook-Pro:DGuy joelcnz$


Run "dub build --force --verbose" to see command it uses for linking. 
Run that command manually and append "-L-v" (without quotes) to see the 
verbose output from the linker.


--
/Jacob Carlborg

Re: [OT] Some neat ideas from the Kotlin language

[Andrei Alexandrescu via Digitalmars-d]

On 02/23/2016 09:58 AM, Xinok wrote:


Option is an enum type in Rust (i.e. algebraic data type). The Rust
compiler forces you to check all possible cases so you can't use it
improperly. So you would have to use something like pattern matching or
"if let" to check the state.

https://doc.rust-lang.org/book/match.html#matching-on-enums


Probably we can do the same in a library: never allow the value out of 
an Option, but provide a visitor with two aliases (ham/spam). There was 
a related PR in Phobos, wasn't there? -- Andrei

Using DList with capacity constraint (aka circular buffer)?

[Seb via Digitalmars-d]

Hey all,

this is yet another post about phobos (missing) data structures 
;-)
I know this has been discussed quite a bit - [1,2,3] to name a 
few.


While it would be nice to have those "trivially to implement" 
wrappers for some common use cases (map, unordered map, set, 
multiset, ...) [1], this question focuses solely on dequeues.


It is great that we have DList, so having a circular buffer (aka 
constrained queue) should be easy.


I do understand that baking this into DList  (as e.g. Python 
does) might (a) make things more complex or (b) add overhead that 
isn't needed for every user.


However my question is: why is there not a neat wrapper around 
DList with a capacity constraint?


Unfortunately we don't have inheritance for structs, but proxying 
most methods should work too (see e.g [4]).


1) Has anyone else missed deque with capacity constraints?
2) Would such a wrapper fit into phobos?
3) Would you prefer (a) a wrapper around DList [4], (b) around 
arrays [5] or (c) a "vanilla" circular queue?

(b is slower, but allows indexing)

Best wishes,

[1] 
https://stackoverflow.com/questions/7162274/why-is-d-missing-container-classes
[2] 
http://forum.dlang.org/thread/mailman.852.1359488662.22503.digitalmar...@puremagic.com
[3] 
http://forum.dlang.org/post/mailman.394.1358112013.22503.digitalmar...@puremagic.com

[4] http://dpaste.dzfl.pl/d8de9325e9a3
[5] http://rosettacode.org/wiki/Queue/Usage#Faster_Version

Re: Vulkan bindings

[Thomas Brix Larsen via Digitalmars-d]

On Wednesday, 24 February 2016 at 12:45:13 UTC, Nicholas Wilson 
wrote:

On Thursday, 18 February 2016 at 04:11:39 UTC, ZombineDev wrote:

[...]


Hey I've started work on a more D like vulkan

http://dpaste.dzfl.pl/1ecfa367b966

I switched to adapting Satoshi bindings
(I gave up on trying to gen it from the xml too much like hard 
work

Way too many inconsistencies )

If you have any further ideas for improvements let me know!
(I think a tool to autogen the descriptor layouts would be 
awesome
But that will take a while and Uni starts soon so I probably 
won't have time)


Nic


Did you look into adapting VkCppGenerator for the task?

https://github.com/nvpro-pipeline/vkcpp

[Issue 7054] std.format.formattedWrite uses code units count as width instead of characters count

[via Digitalmars-d-bugs]

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

--- Comment #12 from Marco Leise  ---
(In reply to hsteoh from comment #10)
> Even if we concede that modern terminals ought to be Unicode-aware (if not
> fully supporting Unicode), there is still the slippery slope of how to print
> bidirectional text, vertical text, scripts that require glyph mutation,
> etc.. Where does one draw the line as to what writefln ought/ought not
> handle?

I tend to think like Steward. If I was using a script other than Latin,
Cyrillic and similarly simple scripts I would most likely expect writefln's
output on a terminal to look like when I print a text file of the same script
to the terminal. Mixing vertical and horizontal text on a terminal is painfully
hard and my expectation is that there is at most an option to render either
horizontally or vertically (transposed). In that case "minimal width" would
become "minimal height" and we are out of trouble.

What exactly do you mean by glyph mutation? In most cases it is probably a task
for the text layout engine the terminal uses. In other cases the user of
writefln should be aware of how their script will display on a terminal and
prepare their text accordingly before printing. There is no simple way to make
plurals work in all languages either:
http://localization-guide.readthedocs.org/en/latest/l10n/pluralforms.html
Is that comparable to what you had in mind?

--

Re: Dynamic pitch shift

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 10:33:56 UTC, Tanel Tagaväli 
wrote:

Hello!

I've been making some progress on the native D audio front:
https://github.com/clinei/daud/tree/28ac042a16ae6785605a9a501b5f867c8f962055

It's a continuous waveform generator, currently outputting a 
saw wave that changes pitch every 1K frames.


Generating a saw waveform for an LFO is the same as generating 
the phase, which is easy to do with using D's modular integers. 
Just add the delta and let it wrap.


If you are generating it for a VCO then you need a bandlimited 
oscilator:


https://ccrma.stanford.edu/~juhan/vas.html

(Abrupt changes in pitch will cause a discontinuity in the second 
derived which is audible, so you might want to interpolate.)

[Issue 11176] array.ptr in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #9 from Kenji Hara  ---
One another way I can think is, array.ptr property would add a hidden check
`arr.length != 0` under @safe code, then returns `null` instead when the length
is 0.

@safe ubyte* oops1(ubyte[] b) {
return b.ptr;
}

@safe ubyte oops2(ubyte[] b) {
return *b.ptr;
}

void main() {
auto b = new ubyte[42];

assert(oops1(b[0 .. $]) is [0]);
assert(oops1(b[0 .. 1]) is [0]);

assert(oops1(b[0 .. 0]) is null);   // the 'safer' behavior

// With the proposed behavior, this call will cause null pointer
dereference,
// then it's deterministic and does not cause undefined behavior.
oops2(b[0 .. 0]);
}

--

Re: Dynamic pitch shift

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 10:33:56 UTC, Tanel Tagaväli 
wrote:

Hello!

I've been making some progress on the native D audio front:
https://github.com/clinei/daud/tree/28ac042a16ae6785605a9a501b5f867c8f962055

It's a continuous waveform generator, currently outputting a 
saw wave that changes pitch every 1K frames.


I have a slight problem, however.
Due to the frequency changing in the middle of a wave, I have 
to patch the new waveform together with the last, which I've 
done with `countUntil` at daud/gen.d:211 (I don't need to call 
popFrontN because the range is a reference type).


However, when calling `RepeatingGenerator.frequency`, the value 
of `_repeat.front` is not the value of the last frame.

app.d:61 is a temporary hack.


How could I get the value currently passed through `cont` from 
`_repeat`?


So the buffer holds one period of the waveform?
I'm assuming that you are nowhere near the Niquist limit.
What is your harmonic distortion rate like?
If it's just for audio how much additional distortion would you 
gain from just resetting the wave from the beginning?


Also your static if (false) for debugging ... debug(statement) is 
a thing for a reason :)


Nic

Re: Vulkan bindings

[Nicholas Wilson via Digitalmars-d]

On Thursday, 18 February 2016 at 04:11:39 UTC, ZombineDev wrote:
On Thursday, 18 February 2016 at 03:27:55 UTC, Alex Parrill 
wrote:

[...]


I started working on that. I've been reading the Python C 
Header generator code and I'm wondering if would be easier to 
just re-implement it in D, rather than trying to extend it. 
Currently the XML is very C oriented (e.g. has C macros in it), 
unlike the OpenGL spec which was written in a language agnostic 
way.


The advantages of using the vk.xml is that once the generator 
is complete you can easily adapt it for newer revisions of the 
spec. Also you have much more freedom in how you can organize 
the bindings (split by functions/structs/enums or logically by 
e.g. instance, device, command recording, queues, 
synchronization, shaders, pipelines, etc.), also it's easier to 
do other stuff like using D's builtin types instead of cstdint, 
generating ddoc-formatted function/struct/enum documentation 
and also ddoc-ed unittests from the spec examples. And maybe 
also provide two versions - one with vanilla names (easier if 
you are following tutorials) and one that's written in D style 
(http://dlang.org/dstyle.html) for those who prefer a more 
uniform syntax with the rest of the other D libraries out there.


I have completed the SPIR-V D header (which was trivial to 
generate from the .json file) and I'm also hoping to translate 
the other stuff from the LunarG SDK like the debug layers (no 
auto-generation would be possible there).


Given the advancements in the recent years of the D ecosystem 
(dub, high quality doc generators, CT generation of 
boilerplate, etc.), I think that D can offer even better 
developer experience than C++ for which the API was primary 
targeted.


Hey I've started work on a more D like vulkan

http://dpaste.dzfl.pl/1ecfa367b966

I switched to adapting Satoshi bindings
(I gave up on trying to gen it from the xml too much like hard 
work

Way too many inconsistencies )

If you have any further ideas for improvements let me know!
(I think a tool to autogen the descriptor layouts would be awesome
But that will take a while and Uni starts soon so I probably 
won't have time)


Nic

[Issue 15593] ctRegex: "munmap_chunk(): invalid pointer"

[via Digitalmars-d-bugs]

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

--- Comment #1 from Kenji Hara  ---
There's some questions.

1. This is reported as a regression issue, so which version had been worked
well?
2. The attached code contains a unittest block, and main function tests command
line arguments or stdin. With the No.1 question, I'm not sure which part would
*fail*. Please tell me the full steps to reproduce issue.

--

Re: C++ UFCS update

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 24 February 2016 at 08:46:40 UTC, wobbles wrote:

On Wednesday, 24 February 2016 at 07:23:03 UTC, Suliman wrote:
On Wednesday, 24 February 2016 at 07:19:02 UTC, Walter Bright 
wrote:

It's a matter of taste I think.
I find 'and's and 'or's less readable than && and ||.

I suspect that's because I'm used to looking at them.


Well, I use "&&" and not "and" in C++, although I think I ought 
to use "and" because long sequences of sigils is harder to 
separate. If anything the fact that C++ programmers don't use 
"and" and "or" shows how strong the effect of cultural influence 
is on "spelling".  I am pretty sure that if "&&" had been 
introduced later than "and", then the roles had been switched.


Interestingly Pony is enforcing parentheses on most operators, 
under the assumption that programmers often get precedence rules 
wrong. Which is good for correctness. They could probably loosen 
it up a bit, but it is better than what we see in the C-family of 
languages.

Re: Dynamic pitch shift

[Tanel Tagaväli via Digitalmars-d-learn]

Sorry for the confusing state of the codebase.

Only the saw wave generator is currently functional, the `saw` 
and `sine` functions are not used and should be left out of 
analysis.


Also, audio output is only to ALSA.

[Issue 15719] New: Can't make template with name "this"

[via Digitalmars-d-bugs]

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

  Issue ID: 15719
   Summary: Can't make template with name "this"
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: lasssa...@gmail.com

You can't have a template inside an aggregate with the name "this".
This prevents one from creating an advanced function template.

This works:

struct S {
this(int i)(float f) {}
}

This doesn't:

struct S {
template this(int i) {
this(float f) {}
}
}

--

[Issue 11176] array.ptr in @safe code

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||ntrel-...@mybtinternet.com

--- Comment #8 from Nick Treleaven  ---
(In reply to David Nadlinger from comment #2)
> The easiest fix would be to just disallow accessing the .ptr property in
> @safe code. There probably wouldn't be much reason to use it in the first
> place anyway.

Maybe, but it should be safe to allow comparing a .ptr with another pointer, so
long as .ptr is not dereferenced. So comparisons are fine, dereference should
be disallowed, and copying/escaping .ptr disallowed. I expect this may be worth
implementing to limit code breakage better than disallowing .ptr entirely.

--

Precision of double in toJSON(and in general)

[Idan Arye via Digitalmars-d]

http://dpaste.dzfl.pl/9a0569b20756

toJSON is converting to the default precision, that fits `float`, 
even though the actual type is `double`. In general, printing 
`double` with "%s" fits `float` more than `double`.


The problem, as I understand it, is that "%s" is converted to 
"%g" instead of "%f" for both `float`s and `double`s. I assume 
that's because "%f" is always printed in fixed-point format, 
while "%g" can choose between the fixed-point and the scientific 
formats.


This is all well for regular printing, but when converting to 
JSON we needlessly lose precision. Wouldn't it be better to 
convert to JSON using "%f", or to generally increase the 
precision of `double` when using "%s"?

Re: std.xml2 (collecting features)

[Dejan Lekic via Digitalmars-d]

If you really want to be serious about the XML package, then I 
humbly believe implementing the commonly-known DOM interfaces is 
a must. Luckily there is IDL available for it: 
https://www.w3.org/TR/DOM-Level-2-Core/idl/dom.idl . Also, 
speaking about DOM, all levels need to be supported!


Also, I would recommend borrowing the Tango's XML pull parser as 
it is blazingly fast.


Finally, perhaps integration with signal/slot module should 
perhaps be considered as well.

[Issue 4763] Few possible changes on std.stdio.File

[via Digitalmars-d-bugs]

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

--- Comment #6 from Sobirari Muhomori  ---
Performance of `open` is an implementation detail, but deprecation applies to
interface. I'd say fix implementation to serve the intended purpose of the
method. If it's impossible or undesirable then deprecate the method.

--

Re: constant expression

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

On Tuesday, 23 February 2016 at 08:00:24 UTC, Nicholas Wilson 
wrote:

Silly question. Why is this necessary?


Due to a problem with the implementation, associative arrays 
currently can't be initialized statically. We hope it will 
eventually get fixed, but until then, you have to use module 
constructors as a workaround.

Dynamic pitch shift

[Tanel Tagaväli via Digitalmars-d-learn]

Hello!

I've been making some progress on the native D audio front:
https://github.com/clinei/daud/tree/28ac042a16ae6785605a9a501b5f867c8f962055

It's a continuous waveform generator, currently outputting a saw 
wave that changes pitch every 1K frames.


I have a slight problem, however.
Due to the frequency changing in the middle of a wave, I have to 
patch the new waveform together with the last, which I've done 
with `countUntil` at daud/gen.d:211 (I don't need to call 
popFrontN because the range is a reference type).


However, when calling `RepeatingGenerator.frequency`, the value 
of `_repeat.front` is not the value of the last frame.

app.d:61 is a temporary hack.


How could I get the value currently passed through `cont` from 
`_repeat`?

Re: C++ UFCS update

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 23 February 2016 at 20:49:40 UTC, Timon Gehr wrote:

On 23.02.2016 21:35, Ola Fosheim Grøstad wrote:
I find it ironic that Walter objects to reusing operators such 
as "<<"

while he is reusing "!" for templates


No reusing and no irony here. "!" for template instantiation is 
a binary usage.


Wrong. Unary, postfix, prefix, mixfix does not matter. It still 
affects usability.


Definition for "operator":

«a symbol or function denoting an operation (e.g. ×, +).»

Re: [OT] Some neat ideas from the Kotlin language

[Kagamin via Digitalmars-d]

On Tuesday, 23 February 2016 at 22:03:32 UTC, Xinok wrote:

On Tuesday, 23 February 2016 at 19:43:43 UTC, rsw0x wrote:

...
How does this differ from the example I gave where the branch 
is only taken if the pointer is non-null?


D doesn't prevent you from dereferencing a null pointer whereas 
these scenarios should be impossible in Kotlin as well as Rust. 
Case and point, this code compiles without issue but crashes at 
runtime:


int* foo()
{
return null;
}

void main()
{
if(int* ptr = new int)
{
ptr = foo();  // Whoops...
*ptr = 35;// Crash
}
}

In D, pointers and reference types can spontaneously become 
null under almost any context. That's the difference.


The idea is to match non-null pointers, this is how you do it:

int* foo()
{
return null;
}

void main()
{
if(int* ptr = foo())
{
*ptr = 35;// no crash
}
}

Re: C++ UFCS update

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 24 February 2016 at 07:25:13 UTC, Dominikus Dittes 
Scherkl wrote:

stdout << "double value is: " << i<<1;

Oops.


error: invalid operands of types '_IO_FILE*' and 'const char 
[18]' to binary 'operator<<'


This happens, and you won't notice until someone complains 
about the wrong value in the output.


Only a neophyte would make such a mistake. Thanks to the messy 
precedence for operators in C you always have to be careful with 
parentheses.


in D neither ! nor ~ is "reused". They are both unary operators 
in C. D only defined new binary operators which use the same 
characters, but there is no way to confuse them.


I am used to D-advocates blindly defending any position, but 
claiming that symbols aren't reused in D isn't a position I would 
expect anyone to defend. Unary or binary is not the issue.


if(!a!(c,!d)(!e)){...}
a~=3;
b=~3;

On the other side having two different "piplining" operators 
"." and "->" makes refactoring the code an ugly mess: If you 
decided to use a reference parameter instead of a pointer you 
have to replace all "->" by ".". But oops, there is still a 
pointer within the referenced struct?


In C++ I typically use "&" or "&&" references instead of 
pointers. In D's "Unique" you get weak duck-typing where you risk 
accessing a member of Unique instead of the object.


However for C++ smart pointers you generally use "->" so you get 
strong typing.

Re: Head Const

[Atila Neves via Digitalmars-d]

On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote:

rears its head again :-)

Head Const is what C++ has for const, i.e. it is not 
transitive, applies to one level only. D has transitive const.


What head const will do for us:

1. make it easy to interface to C++ code that uses const, as 
currently it is not very practical to do so, you have to resort 
to pragma(mangle)


2. supports single assignment style of programming, even if the 
data is otherwise mutable


The downside is, of course, language complexity.


I think that increasing language complexity for the sake of C++ 
integration is a dubious trade-off, especially since "all" that's 
required is correct name mangling. There's no guarantee of what 
the C++ side can do with any type of constness anyway, I'd say 
that any "extern(C++)" mangles as C++ would and leave it at that.


Atila

[Issue 15718] New: use ref or out parameters in the anonymous method may cause error

[via Digitalmars-d-bugs]

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

  Issue ID: 15718
   Summary: use ref or out parameters in the anonymous method may
cause error
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: mzfh...@foxmail.com

use ref or out parameters in the anonymous method may cause error,
for example:

void delegate() test1(ref int a,ref int b,ref int c)
{  
return {
a=1;
b=2;
c=3; 
};
}

void delegate() test2()
{
int i;
int a;
int b;
int c;
auto p = test1(a,b,c);
return p;
}

void test3(void delegate() p)
{  
int[3] arr;

p();

writeln(arr);//arr output: 1,2,3
} 

void main(string[] args)
{ 
auto p = test2();
test3(p);
}

--

Re: C++ UFCS update

[wobbles via Digitalmars-d]

On Wednesday, 24 February 2016 at 07:23:03 UTC, Suliman wrote:
On Wednesday, 24 February 2016 at 07:19:02 UTC, Walter Bright 
wrote:

On 2/23/2016 12:35 PM, Ola Fosheim Grøstad wrote:

[...]


Hardly. ! is not an overloadable operator in D, and ! has no 
binary operator meaning other than for template argument 
lists. I.e. it is not "reuse" at all.


Furthermore, iostreams' use of << is neither thread-safe nor 
exception-safe, though its designer could be forgiven because 
iostreams predates both concepts. The only interesting thing 
about iostreams is why it wasn't deprecated 20 years ago, 
despite being ugly, not thread-safe, not exception-safe, and 
slow.


Could you add to D operators like AND OR etc instead of && ||. 
Words are more readable.


It's a matter of taste I think.
I find 'and's and 'or's less readable than && and ||.

I suspect that's because I'm used to looking at them.

Re: Installing DUB on OSX

[Joel via Digitalmars-d-learn]

On Wednesday, 24 February 2016 at 07:35:40 UTC, Jacob Carlborg 
wrote:

On 2016-02-24 07:49, Joel wrote:


I get this:

Joels-MacBook-Pro:bin joelcnz$ ln -s /usr/local/bin/dub 
/usr/bin

ln: /usr/bin/dub: Operation not permitted
Joels-MacBook-Pro:bin joelcnz$


If you have OS X 10.10.x or lower you can prefix the command 
with "sudo". If you have OS X 10.11 or later you cannot write 
to /usr/bin.


I have OS X version 10.11.3

What about adding another path to $PATH? I don't know how though.

I get this with DUB:

Joels-MacBook-Pro:DGuy joelcnz$ dub --force
Performing "debug" build using dmd for x86_64.
Build directory 
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-353A83191ABC652C7DFA10932343301C/ is not writable. Falling back to direct build in the system's temp folder.

dsfml:system 2.1.0: building configuration "library"...
Build directory 
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-265846E0F1E3C7406127D9762F1360F9/ is not writable. Falling back to direct build in the system's temp folder.

dsfml:audio 2.1.0: building configuration "library"...
Build directory 
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-D924A3C3A5A575D51B048A1FD5A04C95/ is not writable. Falling back to direct build in the system's temp folder.

dsfml:window 2.1.0: building configuration "library"...
Build directory 
../../../.dub/packages/dsfml-2.1.0/.dub/build/library-debug-posix.osx-x86_64-dmd_2070-68F7517C342E684747C39849DE501687/ is not writable. Falling back to direct build in the system's temp folder.

dsfml:graphics 2.1.0: building configuration "library"...
Build directory 
.dub/build/application-debug-posix.osx-x86_64-dmd_2070-2EBE4466CF46539CC1D524962E530835/ is not writable. Falling back to direct build in the system's temp folder.

jex ~master: building configuration "application"...
Linking...
2016-02-24 21:06:38.614 xcodebuild[1076:208774] [MT] 
PluginLoading: Skipping plug-in at path '/Library/Application 
Support/Developer/Shared/Xcode/Plug-ins/D for Xcode.xcplugin' 
because it is not compatible with this version of Xcode.
2016-02-24 21:06:40.157 xcodebuild[1079:208795] [MT] 
PluginLoading: Skipping plug-in at path '/Library/Application 
Support/Developer/Shared/Xcode/Plug-ins/D for Xcode.xcplugin' 
because it is not compatible with this version of Xcode.

ld: can't write output file: jex for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)

--- errorlevel 1
dmd failed with exit code 1.
Joels-MacBook-Pro:DGuy joelcnz$