Re: Silicon Valley D Meetup January 28, 2016

[Ali Çehreli via Digitalmars-d-announce]

On 01/28/2016 08:37 PM, Adam D. Ruppe wrote:
> I've been listening in on this

Why didn't you say hi? :) This has been the first time that we didn't 
have the attendance list open, so we didn't even know whether others 
were connected. Come to think of it, I think we were seeing just two 
connections: Luís and us. Perhaps it was showing just the attendees who 
had video enabled? Anyway...


> and the talk about @nogc on constructors highlights the need to me
> of having more attribute inference.

Is there a reason why only auto functions have attribute inference? Why 
not infer all attributes unless they are overridden by explicit attributes?


> Yes, it works on templates, but not all methods are templates.

Agreed.

Ali

[Issue 15621] std.file.rename does not allow moving files to a different drive

[via Digitalmars-d-bugs]

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

yebblies  changed:

   What|Removed |Added

   Keywords||pull
   Assignee|nob...@puremagic.com|yebbl...@gmail.com

--- Comment #1 from yebblies  ---
Windows rename: https://msdn.microsoft.com/en-us/library/zw5t957f.aspx
MoveFileExW:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365240(v=vs.85).aspx

https://github.com/D-Programming-Language/phobos/pull/3960

--

Re: `alias this` pointers and typeof(null)

[Andrea Fontana via Digitalmars-d]

On Friday, 29 January 2016 at 13:38:20 UTC, Tomer Filiba wrote:
I can change all such invocations into ``func(FooPtr(null))`` 
but it's tedious and basically requires me to compile tens of 
times before I'd cover everything. Is there some workaround to 
make null implicitly convertible to my alias-this type? I mean, 
it's Foo* would accept `typeof(null)` so why can't FooPtr with 
an alias-this to Foo* do so too?


-tomer


What about this:
http://dpaste.dzfl.pl/3305cdf8b7b4
?

Andrea

Re: Overriding opEquals in classes, for comparison with things that aren't Objects

[Mike Parker via Digitalmars-d-learn]

On Friday, 29 January 2016 at 15:00:59 UTC, pineapple wrote:
With this bit of code, the first method seems to work fine - 
things go as expected. But I get a compile error with the 
second method, and I'm not sure how else to write this.


override bool opEquals(Object value) const{
return this.equals(cast(typeof(this)) value);
}
override bool opEquals(T)(T value) const if(isNumeric!(T)){
return this.equals(value);
}

The compile errors I get look like this:

C:\path\to\file.d(477): Error: function 
units.quantity.opEquals!int.opEquals cannot override a 
non-virtual function
C:\path\to\file.d(519): Error: template instance 
units.quantity.opEquals!int error instantiating


How can I revise this so that I can override comparison 
operators for things other than class instances?


The first implementation is fine because you're overriding the 
implementation in the base class (Object). However, the second 
one fails because it's a template. Templates are non-virtual and 
cannot override anything. Even if you could, there is no such 
implementation in Object and, therefore, nothing to override.


Templated functions can be used as overloads, though, but I'm not 
sure off the top of my head if the compiler accepts templated 
opEquals on classes at all. My guess is no, but you can find out 
by removing the override from the template declaration. If not, 
you should be able to implement non-templated overloads for the 
types you're interested in (without the override keyword, mind 
you, since they won't be overriding anything).

Re: Why is it a memory ERRO.

[Mike Parker via Digitalmars-d-learn]

On Friday, 29 January 2016 at 13:22:07 UTC, Mike Parker wrote:

Your problem is probably that you are calling GC.free in the 
destructor. Don't do this. You don't need to call GC.free at 
all. The GC will collect both your object instance and the 
memory you allocated with new. Never, ever, manipulate GC 
memory in the destructor of a GC-managed object.


Here's a modified version of your program. Every time it prints, 
you know the garbage collector has just run a collection cycle. 
Every class instance and every 'by' that is allocated will 
eventually be free. Not all destructors are guaranteed to run 
during the program's lifetime, though. Some will be run after 
main exits and the GC shuts down.


import core.thread;
import std.stdio;

class MyClass
 {
   this(){
   by = new ubyte[1];
   id = i;
   ++i;
   }
   ~this() {
   writeln("freed #", id);
   }
 private:
   ubyte[]   by;
   int id;
   static int i;
 };

void main()
{
while(true) {
   auto obj = new MyClass;
   Thread.sleep(5.msecs);
   if(MyClass.i == 2000)
break;
}
}

`alias this` pointers and typeof(null)

[Tomer Filiba via Digitalmars-d]

I had a struct (Foo) that was passed by pointer (i.e., Foo*) 
throughout my code. To prevent dangling pointers, I created a 
`FooPtr` struct with an `alias this` that does some checks before 
returning me the underlying pointer. This is sort-of what I have:


struct FooPtr {
Foo* ptr;

this(Foo* p) {ptr = p;}
@property auto get() {return ptr;}
alias get this;
}

I changed all `Foo*` into `FooPtr` and it's great, but I have 
numerous places where `null` is used literally, and its type is 
`typeof(null)`. So


void func(FooPtr x) {}
func(null);

fails with ``Error: function func (FooPtr x) is not callable 
using argument types (typeof(null))``


I can change all such invocations into ``func(FooPtr(null))`` but 
it's tedious and basically requires me to compile tens of times 
before I'd cover everything. Is there some workaround to make 
null implicitly convertible to my alias-this type? I mean, it's 
Foo* would accept `typeof(null)` so why can't FooPtr with an 
alias-this to Foo* do so too?


-tomer

Re: Movable resource handles

[Matt Elkins via Digitalmars-d]

On Thursday, 28 January 2016 at 06:13:32 UTC, Era Scarecrow wrote:
On Thursday, 28 January 2016 at 05:39:55 UTC, Era Scarecrow 
wrote:
 It really comes down to that an array qualifies as an Lvalue 
operator; But I _think_ this is a bug in the language since 
you should be able to assign a new Rvalue to a new array 
element just being created/added. We'll have to get input from 
Walter or Andrei.


 Alright, closest bug match i could find is 
https://issues.dlang.org/show_bug.cgi?id=7032 which is sorta 
the same thing, but not quite...


Ah, ok. A bug is better than a language design limitation -- it 
might get fixed at some point! I'll figure out a workaround for 
my use case.


Thanks for all the time you spent, I appreciate the help.

Re: reduce -> fold?

[Luís Marques via Digitalmars-d]

On Friday, 29 January 2016 at 13:56:48 UTC, Dragos Carp wrote:
But not in python, where "accumulate"[1] is the generic 
equivalent of C++ "partial_sum"[2]. I like "fold" more.


BTW this week, a colleague of mine implemented a python 
"accumulate" in D. Is there any interest to contribute it to 
Phobos? How should this be named?


[1] 
https://docs.python.org/3/library/itertools.html#itertools.accumulate

[2] http://en.cppreference.com/w/cpp/algorithm/partial_sum


Fair enough. Yes, that is indeed a useful algorithm, so please do 
contribute. I won't bikeshed on that other name, heh.

Re: reduce -> fold?

[Dragos Carp via Digitalmars-d]

On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote:
Just to bikeshed a little, I remember that when I first started 
using std.algorithm I was ctrl-F'ing for "accumulate" and not 
finding it quite often. D competes with C++ directly, so do 
consider that name :-)


But not in python, where "accumulate"[1] is the generic 
equivalent of C++ "partial_sum"[2]. I like "fold" more.


BTW this week, a colleague of mine implemented a python 
"accumulate" in D. Is there any interest to contribute it to 
Phobos? How should this be named?


[1] 
https://docs.python.org/3/library/itertools.html#itertools.accumulate

[2] http://en.cppreference.com/w/cpp/algorithm/partial_sum

Overriding opEquals in classes, for comparison with things that aren't Objects

[pineapple via Digitalmars-d-learn]

With this bit of code, the first method seems to work fine - 
things go as expected. But I get a compile error with the second 
method, and I'm not sure how else to write this.


override bool opEquals(Object value) const{
return this.equals(cast(typeof(this)) value);
}
override bool opEquals(T)(T value) const if(isNumeric!(T)){
return this.equals(value);
}

The compile errors I get look like this:

C:\path\to\file.d(477): Error: function 
units.quantity.opEquals!int.opEquals cannot override a 
non-virtual function
C:\path\to\file.d(519): Error: template instance 
units.quantity.opEquals!int error instantiating


How can I revise this so that I can override comparison operators 
for things other than class instances?

Re: Overriding opEquals in classes, for comparison with things that aren't Objects

[pineapple via Digitalmars-d-learn]

It also occurred to me to do something like this, but it isn't 
accepted either.


override bool opEquals(T)(T value){
return this.equals(value);
}

Re: Why is it a memory ERRO.

[Mike Parker via Digitalmars-d-learn]

On Friday, 29 January 2016 at 12:43:53 UTC, Dsby wrote:

the Code:



~this(){
GC.free(by.ptr);
by = null;
writeln("free");
}


Your problem is probably that you are calling GC.free in the 
destructor. Don't do this. You don't need to call GC.free at all. 
The GC will collect both your object instance and the memory you 
allocated with new. Never, ever, manipulate GC memory in the 
destructor of a GC-managed object.

Re: `alias this` pointers and typeof(null)

[Tomer Filiba via Digitalmars-d]

On Friday, 29 January 2016 at 13:59:15 UTC, Andrea Fontana wrote:

What about this:
http://dpaste.dzfl.pl/3305cdf8b7b4
?

Andrea


Thanks Andrea, I thought about it but it requires duplicating all 
function signatures (and not in an automatic manner). Btw, you 
can also write ``void func(typeof(null) x) {}`` instead.

Re: D vs Rust

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 29 January 2016 at 07:01:07 UTC, Sönke Ludwig wrote:

Am 29.01.2016 um 00:18 schrieb Ola Foaheim Grøstad:

D is closer to C++ style templating and OO, and currently focus
on enabling binding to non-template C++ libraries.


Small correction: Should be "binding to template based C++ 
libraries" - non-template libraries have worked more or less 
for a while now.


I was thinking of Walter's work on supporting C++ exceptions as 
completing the effort to bind to non-templated libraries; 
exceptions being the "return value" for failure.


Is there an effort to support templated libraries? They are often 
fully inlined and header-only?

Re: D vs Rust

[qznc via Digitalmars-d]

On Thursday, 28 January 2016 at 22:30:51 UTC, nbro wrote:
Apart from [syntax], what are the real advantages of D over 
Rust?


D is a broader language and is applicable in more situations.

In many cases you don't care and don't want to care about memory 
management. Use D and its garbage collector and be done with it. 
Rust forces you to think about memory management all the time, 
because it type checks life times. If you hit some performance 
wall during development, then Ds toolbox allows you to work 
around the GC in specific places. So, convenience first and 
performance where necessary. No premature optimization.


If you need more programmers, D is easier to learn, due to its 
syntax. Simple C, Java and even C++ programs can be very directly 
ported to D. For example, the D compiler frontend was converted 
from C++ to D algorithmically. This does not work with Rust, 
where the type checker will complain a lot.


D is more mature than Rust at the moment. Less backwards 
incompatible changes. More reliability and stability.


D has three different backends with different strengths. With dmd 
you have really fast compilation, which is great for development. 
With the LLVM and GCC backends you get better performance for 
release builds. With GCC you can compile for many architectures 
(although you might need to port the runtime).

Re: What are the real GUI toolkits for D?

[interessted via Digitalmars-d]

On Friday, 29 January 2016 at 10:18:31 UTC, interessted wrote:

On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote:

On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote:
Except for GtkD and DWT, D does not seem to be supported by a 
really nice GUI toolkit.


For Windows DFL is quite nice and working well (I've used it 
in several projects).



where can one find a working DFL version - compilable with the 
last compiler?


sorry forgot  -  and running for win64, since nobody i know still 
uses/creates x32.

Re: C++17

[Ola Fosheim Grøstad via Digitalmars-d]

https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/

Mentions D.

Re: reduce -> fold?

[Adrian Matoga via Digitalmars-d]

On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu 
wrote:
As has been discussed before there's been discussion about 
std.algorithm.reduce taking the "wrong" order of arguments (its 
definition predates UFCS). I recall the conclusion was there'd 
be subtle ambiguities if we worked reduce to implement both 
orders.


So the next best solution is to introduce a new name such as 
the popular "fold", and put them together in the documentation.



Thoughts?


YES!

There was a topic on this [1] and some implementation proposed. 
I'm not sure if it was the only one.


[1] 
http://forum.dlang.org/post/sqbizjwcyavbrxwag...@forum.dlang.org

Re: reduce -> fold?

[Luís Marques via Digitalmars-d]

On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu 
wrote:
So the next best solution is to introduce a new name such as 
the popular "fold", and put them together in the documentation.


Just to bikeshed a little, I remember that when I first started 
using std.algorithm I was ctrl-F'ing for "accumulate" and not 
finding it quite often. D competes with C++ directly, so do 
consider that name :-)

Re: What are the real advantages that D offers in multithreading?

[Thiez via Digitalmars-d]

On Thursday, 28 January 2016 at 22:59:58 UTC, cym13 wrote:
On Thursday, 28 January 2016 at 11:53:48 UTC, Russel Winder 
wrote:
It should be pointed out that anyone using the synchronized 
keyword anywhere in Java code is doing concurrent and parallel 
programming wrong. If they are using synchronized in single 
threaded programming well, then…


[...]


I have seen you talk about this before and I too would love you 
to elaborate on the subject.


One of the most obvious problems with using `synchronized` on 
methods, or using `synchronized(this)`, is that an object has no 
control over its monitor. All code that can see a particular 
instance can choose to synchronize on that instance, which 
creates opportunities for deadlocks. This problem can be avoided 
by controlling access to the monitor you use. One of the easiest 
ways to control access to your monitor is by having a private 
object to synchronize on (e.g. `private final Object lock = new 
Object();`) instead of synchronizing on `this`. Further 
improvements can be made by explicitly using one of the classes 
found in java.util.concurrent.locks: this allows you to be more 
explicit by, for instance, choosing a ReadWriteLock, and it 
provides access to proper conditions.


Another problem with `synchronized` in Java is that it requires 
all objects to contain an implicit monitor, while the vast 
majority of objects will never get synchronized on: for all those 
objects this is useless overhead. Sadly backwards compatibility 
implies that Java will likely never be able to entirely get rid 
of this overhead.

reduce -> fold?

[Andrei Alexandrescu via Digitalmars-d]

As has been discussed before there's been discussion about 
std.algorithm.reduce taking the "wrong" order of arguments (its 
definition predates UFCS). I recall the conclusion was there'd be subtle 
ambiguities if we worked reduce to implement both orders.


So the next best solution is to introduce a new name such as the popular 
"fold", and put them together in the documentation.



Thoughts?

Andrei

Re: D vs Rust

[Kagamin via Digitalmars-d]

On Friday, 29 January 2016 at 07:01:07 UTC, Sönke Ludwig wrote:
Small correction: Should be "binding to template based C++ 
libraries" - non-template libraries have worked more or less 
for a while now.


Actually less. Without RAII you can't bind any realistic C++ 
library like Qt.

[Issue 15619] [REG 2.068] Floating-point x86_64 codegen regression, when involving array ops

[via Digitalmars-d-bugs]

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

ponce  changed:

   What|Removed |Added

Summary|[REG 2.068] Floating-point  |[REG 2.068] Floating-point
   |x86_64 codegen regression   |x86_64 codegen regression,
   ||when involving array ops

--

Re: What are the real GUI toolkits for D?

[interessted via Digitalmars-d]

On Friday, 29 January 2016 at 11:30:41 UTC, Suliman wrote:

On Friday, 29 January 2016 at 10:41:03 UTC, interessted wrote:

On Friday, 29 January 2016 at 10:18:31 UTC, interessted wrote:

On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote:

On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote:
Except for GtkD and DWT, D does not seem to be supported by 
a really nice GUI toolkit.


For Windows DFL is quite nice and working well (I've used it 
in several projects).



where can one find a working DFL version - compilable with 
the last compiler?


sorry forgot  -  and running for win64, since nobody i know 
still uses/creates x32.


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


thank you.
but trying to compile i get - ex.:

Error		Error: function dfl.control.ControlSuperClass.wndProc does 
not override any 
function		C:\proggies\D\dfl\src\dfl\control.d	6510	


or

SeverityCodeDescription Project FileLineSuppression 
State
Error		Error: overlapping default initialization for field 
droptarget and ldlgcode		C:\proggies\D\dfl\src\dfl\control.d	603	


anything i do wrong?

Re: C++17

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 29 January 2016 at 10:43:08 UTC, Ola Fosheim Grøstad 
wrote:

https://www.reddit.com/r/cpp/comments/41uflq/bjarne_stroustrup_doing_an_ama/

Mentions D.


Since it is in danish, let me quickly translate the informative 
sections:


Bjarne Stroustrup (translated from danish): The safety rules is 
part of the more extensive guidelines 
(https://github.com/isocpp/CppCoreGuidelines ) and supported by a 
small library (https://github.com/microsoft/gsl ) .  We have 
"annotations" which can be used to neutralize the rules (as an 
"unsafe" annotation). We minimize their usage. Our goal is 100% 
safety and I assume that we will get as close to that goals as 
any language that can work directly with hardware. We already 
have 100% resource safety, and that is better than languages like 
Java and C#. I think all languages will become better in these 
areas.»



On garbage collection:

Bjarne Stroustrup (translated from danish): Yes, programming 
language creators and researchers have always been fascinated by 
garbage collection. I think that is a mistake: GC is not general 
- it cannot deal with non-memory resources - and is not ideal - 
it introduces a central facility in (otherwise) distributed 
systems. The good solution is to not produce garbage: 
http://www.stroustrup.com/resource-model.pdf . RAII is central in 
my ideas about programming.



He also acknowledges scandinavian contributions to programming 
languages, the OO languages Simula and Beta.

math libraries

[interessted via Digitalmars-d]

are you handling this in the math libs?

http://milesmathis.com/pi2.html
http://milesmathis.com/pi4.html

Re: What are the real GUI toolkits for D?

[interessted via Digitalmars-d]

On Friday, 29 January 2016 at 12:12:40 UTC, interessted wrote:

On Friday, 29 January 2016 at 11:30:41 UTC, Suliman wrote:

On Friday, 29 January 2016 at 10:41:03 UTC, interessted wrote:

On Friday, 29 January 2016 at 10:18:31 UTC, interessted wrote:
On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon 
wrote:

On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote:
Except for GtkD and DWT, D does not seem to be supported 
by a really nice GUI toolkit.


For Windows DFL is quite nice and working well (I've used 
it in several projects).



where can one find a working DFL version - compilable with 
the last compiler?


sorry forgot  -  and running for win64, since nobody i know 
still uses/creates x32.


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


thank you.
but trying to compile i get - ex.:



fixing some imports etc this remains:
SeverityCodeDescription Project FileLineSuppression 
State
Error		Error: static assert  (136LU == 152LU) is 
false		C:\xxx\D\dfl\src\dfl\filedialog.d	409	

[Issue 15622] New: Order of execution of module destructors is not always correct

[via Digitalmars-d-bugs]

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

  Issue ID: 15622
   Summary: Order of execution of module destructors is not always
correct
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: yazan.dab...@gmail.com

import core.stdc.stdio;
import std.parallelism;

static ~this()
{
printf("%.*s\n", __FUNCTION__.length, __FUNCTION__.ptr);
}

shared static ~this()
{
printf("%.*s\n", __FUNCTION__.length, __FUNCTION__.ptr);
}

void main()
{
auto t = new TaskPool();
t.isDaemon = true;
}

--

The previous code prints:

main._staticDtor1
main._sharedStaticDtor2
main._staticDtor1
main._staticDtor1
main._staticDtor1

--

Per http://dlang.org/spec/module.html#staticorder, shared static destructors
are defined to run after all other static destructors but in this case that is
not happening.

Original bug report: https://github.com/rejectedsoftware/vibe.d/issues/1374

--

d plugin for Intelij Idea debuging support

[Pavel via Digitalmars-d-learn]

Hello!

Is there any debuging support for Intelij Idea's D plugin?

Thanks!

Why is it a memory ERRO.

[Dsby via Digitalmars-d-learn]

the Code:
class MyClass
{
this(){
by = new ubyte[1];
++i;
}
~this(){
GC.free(by.ptr);
by = null;
writeln("free");
}
void show(){
writeln(i);
};
private:
ubyte[]   by;
static i = 0;
};

void main()
{
bool start = true;
int i = 0;
while(start){
auto obj = new MyClass();
obj.show();
Thread.sleep(5.msecs);
//obj.destroy;
//GC.free(cast(void *)obj);
++i;
if (i > 2)
break;
}
}

the code will be :
341
core.exception.InvalidMemoryOperationError@src/core/exception.d(679): Invalid 
memory operation

core.exception.InvalidMemoryOperationError@src/core/exception.d(679): Invalid 
memory operation


.why is it?
if < obj.destroy; > is exec. the code will not errno.

Re: What are the real GUI toolkits for D?

[Luis via Digitalmars-d]

On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote:

On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote:
Except for GtkD and DWT, D does not seem to be supported by a 
really nice GUI toolkit.


For Windows DFL is quite nice and working well (I've used it in 
several projects).





Some one should update the DFL web page and forums. There is a 
few post asking if DFL is dead, when there is at least 3 forks or 
updates to D2 on http://code.dlang.org/search?q=dfl

Re: What are the real GUI toolkits for D?

[Suliman via Digitalmars-d]

On Friday, 29 January 2016 at 10:41:03 UTC, interessted wrote:

On Friday, 29 January 2016 at 10:18:31 UTC, interessted wrote:

On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote:

On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote:
Except for GtkD and DWT, D does not seem to be supported by 
a really nice GUI toolkit.


For Windows DFL is quite nice and working well (I've used it 
in several projects).



where can one find a working DFL version - compilable with the 
last compiler?


sorry forgot  -  and running for win64, since nobody i know 
still uses/creates x32.


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

Re: Why is it a memory ERRO.

[Dsby via Digitalmars-d-learn]

On Friday, 29 January 2016 at 12:43:53 UTC, Dsby wrote:

the Code:
class MyClass
{
this(){
by = new ubyte[1];
++i;
}
~this(){
GC.free(by.ptr);
by = null;
writeln("free");
}
void show(){
writeln(i);
};
private:
ubyte[]   by;
static i = 0;
};

void main()
{
bool start = true;
int i = 0;
while(start){
auto obj = new MyClass();
obj.show();
Thread.sleep(5.msecs);
//obj.destroy;
//GC.free(cast(void *)obj);
++i;
if (i > 2)
break;
}
}

the code will be :
341
core.exception.InvalidMemoryOperationError@src/core/exception.d(679): Invalid 
memory operation

core.exception.InvalidMemoryOperationError@src/core/exception.d(679): Invalid 
memory operation


.why is it?
if < obj.destroy; > is exec. the code will not errno.


I am in 2.069, on opensuse leap 42.1 X86_64
dmd -v
DMD64 D Compiler v2.069
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

Re: What are the real GUI toolkits for D?

[MGW via Digitalmars-d]

I think what to make "pure" GUI for D there is a waste of time 
and forces. More effectively and faster  to develop "wrapper" for 
Qt.


For myself  I have made library QtE which possibilities suffice 
me much. The main feature that addition of a new method or 
property from Qt in QtE occupies only five minutes. By the 
current moment in QtE  is 340 of functions Qt 4.8  "are wrapped 
up".


For beginning studying of programming language D, library QtE is 
the best decision.


QtE is checked up in Windows 32/64 and Linux 32/64 and depends 
from Qt 4.8.x. In the near future I plan to transfer it on MAC OS 
X 10.9 (64).


https://github.com/MGWL/QtE-Qt_for_Dlang_and_Forth

Some screenshots

Screen Windows
http://qte.ucoz.ru/QtE_win_2.png

Screen Linux
http://qte.ucoz.ru/QtE_linux_2.png

simple example:
Hello.d

import qte;
import core.runtime;// parametr start
int main(string[] args) {
bool fDebug;	foreach (arg; args) if (arg=="--debug") fDebug = 
true;

int rez = LoadQt( dll.Core | dll.Gui | dll.QtE, fDebug);
if (rez==1) return 1;  // Error load QtE
QApplication	app = new QApplication(, 
Runtime.cArgs.argv, 1);

QLabel  label = new QLabel(null);
label.setText(“ --- Hello from QtE ---”);
label.setAlignment(QtE.AlignmentFlag.AlignCenter);
label.resize(300, 130);
label.show();
return app.exec();
}


Compile and execute:
rdmd Hello qte

Re: merging map/filter/reduce/... in D

[glathoud via Digitalmars-d-learn]

Thanks. I am glad be wrong on that one.

I had a look at map & filter in the source code ; pleased to see 
they're lazily implemented!


map
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L425

filter
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L924
I had to look for FilterResult!
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L979

Small remark: One could make the laziness of filter a bit more 
clear in the doc though - at least for newbies like me.

http://dlang.org/phobos/std_algorithm_iteration.html

Best regards,
Guillaume

Re: D vs Rust

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 29 January 2016 at 08:26:01 UTC, John Colvin wrote:
It depends what you mean by templated. I believe the 
interoperability work is for the results of instantiated 
templates, not on the templates themselves.


Hmm, not sure how important that is. At least in my C++ class 
templates most member functions tend to be inline, so they 
shouldn't end up in an object file.

Re: What are the real GUI toolkits for D?

[interessted via Digitalmars-d]

On Thursday, 28 January 2016 at 16:57:04 UTC, thedeemon wrote:

On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote:
Except for GtkD and DWT, D does not seem to be supported by a 
really nice GUI toolkit.


For Windows DFL is quite nice and working well (I've used it in 
several projects).



where can one find a working DFL version - compilable with the 
last compiler?

[Issue 15621] New: std.file.rename does not allow moving files to a different drive

[via Digitalmars-d-bugs]

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

  Issue ID: 15621
   Summary: std.file.rename does not allow moving files to a
different drive
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: yebbl...@gmail.com

On windows std.file.rename calls MoveFileExW, which will not move files from
once device to another unless the MOVEFILE_COPY_ALLOWED flag is set.

Since the cstdio function with the same name doesn't have this limitation, and
it's not documented, it seems accidental.

--

Re: D vs Rust

[John Colvin via Digitalmars-d]

On Friday, 29 January 2016 at 08:23:38 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 29 January 2016 at 07:01:07 UTC, Sönke Ludwig wrote:

Am 29.01.2016 um 00:18 schrieb Ola Foaheim Grøstad:
D is closer to C++ style templating and OO, and currently 
focus

on enabling binding to non-template C++ libraries.


Small correction: Should be "binding to template based C++ 
libraries" - non-template libraries have worked more or less 
for a while now.


I was thinking of Walter's work on supporting C++ exceptions as 
completing the effort to bind to non-templated libraries; 
exceptions being the "return value" for failure.


Is there an effort to support templated libraries? They are 
often fully inlined and header-only?


It depends what you mean by templated. I believe the 
interoperability work is for the results of instantiated 
templates, not on the templates themselves.

Re: merging map/filter/reduce/... in D

[cym13 via Digitalmars-d-learn]

On Friday, 29 January 2016 at 08:06:14 UTC, glathoud wrote:

Thanks. I am glad be wrong on that one.

I had a look at map & filter in the source code ; pleased to 
see they're lazily implemented!


map
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L425

filter
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L924
I had to look for FilterResult!
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L979

Small remark: One could make the laziness of filter a bit more 
clear in the doc though - at least for newbies like me.

http://dlang.org/phobos/std_algorithm_iteration.html

Best regards,
Guillaume


While it's not entirely true because one can implement a non-lazy 
range, any time you see the word "range" in the documentation you 
should think that it is lazy. Ranges are an important concept in 
D so we usually don't bother explaining it in the doc. You can 
read about it here if you need to: 
http://ddili.org/ders/d.en/ranges.html and 
http://dlang.org/phobos/std_range.html

Re: Overriding opEquals in classes, for comparison with things that aren't Objects

[pineapple via Digitalmars-d-learn]

On Friday, 29 January 2016 at 15:13:45 UTC, Mike Parker wrote:
The first implementation is fine because you're overriding the 
implementation in the base class (Object). However, the second 
one fails because it's a template. Templates are non-virtual 
and cannot override anything. Even if you could, there is no 
such implementation in Object and, therefore, nothing to 
override.


Templated functions can be used as overloads, though, but I'm 
not sure off the top of my head if the compiler accepts 
templated opEquals on classes at all. My guess is no, but you 
can find out by removing the override from the template 
declaration. If not, you should be able to implement 
non-templated overloads for the types you're interested in 
(without the override keyword, mind you, since they won't be 
overriding anything).


Hm, I should've thought to try that. I was able to get things 
working as I wanted them to by doing this:


override bool opEquals(Object value) const{
return this.equals(cast(typeof(this)) value);
}
bool opEquals(T)(T value){
return this.equals(value);
}

Re: is(some template instantiation) is true, but the actual instantiation fails

[Basile B. via Digitalmars-d-learn]

On Friday, 29 January 2016 at 15:28:29 UTC, Adrian Matoga wrote:

How can I reliably test if CallsFoo can be instantiated?


You can use a constraint to prevent invalid instantiation:

struct HasFoo { void foo() {} }

struct NoFoo {}

struct CallsFoo(T)
if (__traits(hasMember, T, "foo"))
{
T t;
void bar() { t.foo(); }
}

static assert(is(CallsFoo!HasFoo));
static assert(!is(CallsFoo!NoFoo));

Re: Vision for the first semester of 2016

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

On Thursday, 28 January 2016 at 12:40:56 UTC, Ola Fosheim Grøstad 
wrote:
I think that Sonke received too much "negative motivation" for 
his contributions recently, if I had been in his shoes I'd 
probably found working on vibe.d more fun. IRRC Ruppe also have 
voiced that he want to work on libraries which he has more 
freedom with.


Yeah, I think getting in Phobos is a waste of time and likely a 
net negative on the library due to how much harder it is to 
change phobos vs changing your own file.


In my perfect world, quality third party apps - as determined 
just by usage stats or something - would be automatically 
downloadable and their documentation searchable as if it was 
standard.


When you do `import std.string;` you expect it to just work, and 
you find std.string's docs easily from dmd.


I'd love it if you could do `import thirdparty.independent;` and 
it magically works too - without even need for a configuration 
file or an install command. And the docs are right there and 
tutorials are written however the author feels like writing them.



Then the line between "standard library" and other library 
basically disappears.



While that isn't likely to happen, we could at least start 
promoting third party stuff more equally.


An frankly, as APIs have to be vetted on large applications in 
maintenance mode a lot of the effort put into arguing the 
design "perfect Phobos libraries" most likely will be in vain.


This is a reason why I tend to only write libs that I actually 
use myself - at least then I know every function has one happy 
user.

[Issue 15623] New: is(M!N) evaluates to true for M!N that fails to instantiate.

[via Digitalmars-d-bugs]

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

  Issue ID: 15623
   Summary: is(M!N) evaluates to true for M!N that fails to
instantiate.
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@atari8.info

struct HasFoo { void foo() {} }

struct NoFoo {}

struct CallsFoo(T) {
T t;
void bar() { t.foo(); }
}

static assert(is(CallsFoo!HasFoo));
static assert(is(typeof({ alias Baz = CallsFoo!HasFoo; return Baz.init; }(;
static assert(__traits(compiles, { alias Baz = CallsFoo!HasFoo; return
Baz.init; }()));
alias Bar = CallsFoo!HasFoo;

// this should fail:
static assert(is(CallsFoo!NoFoo));
// this should fail too:
static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return Baz.init; }(;
// this too:
static assert(__traits(compiles, { alias Baz = CallsFoo!NoFoo; return Baz.init;
}()));
// only this fails:
//alias Baz = CallsFoo!NoFoo;  // (1)

--

Re: `alias this` pointers and typeof(null)

[Benjamin Thaut via Digitalmars-d]

On Friday, 29 January 2016 at 13:38:20 UTC, Tomer Filiba wrote:


I can change all such invocations into ``func(FooPtr(null))`` 
but it's tedious and basically requires me to compile tens of 
times before I'd cover everything. Is there some workaround to 
make null implicitly convertible to my alias-this type? I mean, 
it's Foo* would accept `typeof(null)` so why can't FooPtr with 
an alias-this to Foo* do so too?


-tomer


Unfortunately D is strictly against implict conversion, so there 
is no way to do this. I also hit this issue a couple of times 
already. But implicitly calling a constructor in C++ is 
considered error prone and therefor not supported in D.


Kind Regards
Benjamin Thaut

Re: What are the real GUI toolkits for D?

[thedeemon via Digitalmars-d]

On Friday, 29 January 2016 at 10:41:03 UTC, interessted wrote:
where can one find a working DFL version - compilable with the 
last compiler?


The last compiler is just 1 day old, don't expect all libs 
updated this soon. ;)


Usually I took DFL here:
https://github.com/Rayerd/dfl/

There are many forks and branches now:
https://github.com/Rayerd/dfl/network

sorry forgot  -  and running for win64, since nobody i know 
still uses/creates x32.


This rep seems quite active, includes 64-bit versions too:
https://github.com/qchikara/dfl/branches

The last version I personally used (32-bit) :
https://github.com/thedeemon/dfl
(includes some my own fixes)

Re: Assert failure on 2.070.0 without stack trace

[Benjamin Thaut via Digitalmars-d-learn]

On Thursday, 28 January 2016 at 18:33:19 UTC, Nordlöw wrote:


Thanks, I'm aware of these tools.

But it's easier to use the stacktrace...if I only get one. The 
function where the assert() is called is, in turn, called in 
hundreds of places.


Which platform are you on? Are all your binaries compiled with 
debug symbols? If one or multiple functions on the stack are 
within phobos or druntime you might not have debug symbols for 
phobos or druntime. Using inline asm might also destroy your 
stack frames.

Re: D vs Rust

[bearophile via Digitalmars-d]

qznc:

On Friday, 29 January 2016 at 09:00:52 UTC, qznc wrote:

D is a broader language and is applicable in more situations.
In many cases you don't care and don't want to care about 
memory management.


Learning to manage memory in Rust takes lot of time and practice, 
it's a bit painful. I am sometimes able to write working D code 
almost as quickly as Python code, but writing similar code in 
Rust takes me much more time.


So I think for both small script-like programs, and general 
application code (where code safety is not the most important 
thing), D wins over Rust.


D is also more flexible (higher order templates, better CTFE, 
unrestricted UFCS, etc), and you can port Python or C code to D 
faster than to Rust.


So I think Rust targets a smaller number of coding purposes 
compared to D. Rust could also replace the code you want to write 
in OcaML, like compiler-like programs (thanks to Rust enums and 
pattern matching).


Safety and correctness of the code are very important for me. 
Regarding safety & correctness I think there's this ordering:


Rust > D > C++14 > C

If you talk about correctness you think about Ada too. Rust code 
seems usually more succinct compared to Ada code. Ada is more 
mature and it has lot of small features missing from Rust/D, that 
help make the code more correct (like integer subsets, static 
invariants, stronger typing for array indexing, SPARK annotations 
to manage global mutables safely, and so on). I don't know if 
such safety features will be added to Rust, I am dubious.


In the C/Ada world you have language subsets like MISRA/SPARK 
that people use in high integrity system. I think Rust still 
lacks something like that.


Bye,
bearophile

Re: reduce -> fold?

[ixid via Digitalmars-d]

On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu 
wrote:
As has been discussed before there's been discussion about 
std.algorithm.reduce taking the "wrong" order of arguments (its 
definition predates UFCS). I recall the conclusion was there'd 
be subtle ambiguities if we worked reduce to implement both 
orders.


So the next best solution is to introduce a new name such as 
the popular "fold", and put them together in the documentation.



Thoughts?

Andrei


Absolutely yes!

Re: reduce -> fold?

[Y via Digitalmars-d]

On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu 
wrote:
As has been discussed before there's been discussion about 
std.algorithm.reduce taking the "wrong" order of arguments (its 
definition predates UFCS). I recall the conclusion was there'd 
be subtle ambiguities if we worked reduce to implement both 
orders.


So the next best solution is to introduce a new name such as 
the popular "fold", and put them together in the documentation.



Thoughts?

Andrei


Yes yes yes please!

Re: reduce -> fold?

[wobbles via Digitalmars-d]

On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu 
wrote:
As has been discussed before there's been discussion about 
std.algorithm.reduce taking the "wrong" order of arguments (its 
definition predates UFCS). I recall the conclusion was there'd 
be subtle ambiguities if we worked reduce to implement both 
orders.


So the next best solution is to introduce a new name such as 
the popular "fold", and put them together in the documentation.



Thoughts?

Andrei


I think yes. Took me ages to realise the difference with reduce.

Re: reduce -> fold?

[Brad Anderson via Digitalmars-d]

On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu 
wrote:
As has been discussed before there's been discussion about 
std.algorithm.reduce taking the "wrong" order of arguments (its 
definition predates UFCS). I recall the conclusion was there'd 
be subtle ambiguities if we worked reduce to implement both 
orders.


So the next best solution is to introduce a new name such as 
the popular "fold", and put them together in the documentation.



Thoughts?

Andrei


+1

Let's make sure to write the half dozen other names for it in the 
documentation so people coming to D from other languages can 
easily find it.


And just for completeness, here is monarchdodra's valiant but 
ultimately unsuccessful pull request which attempted fix reduce: 
https://github.com/D-Programming-Language/phobos/pull/861#issuecomment-20760448

Re: is(some template instantiation) is true, but the actual instantiation fails

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/29/16 10:28 AM, Adrian Matoga wrote:

Code:


struct HasFoo { void foo() {} }

struct NoFoo {}

struct CallsFoo(T) {
 T t;
 void bar() { t.foo(); }
}

static assert(is(CallsFoo!HasFoo));
alias Bar = CallsFoo!HasFoo;

static assert(is(CallsFoo!NoFoo)); // (1)
//alias Baz = CallsFoo!NoFoo;  // (2)


This compiles, although I expected that (1) should fail.
Now try uncommenting (2) and it can't be compiled.

Why does `is(CallsFoo!NoFoo)` evaluate to true if `is(CallsFoo!NoFoo)`
can't be instantiated?
Am I missing something about `is(T)` or is it a bug?
How can I reliably test if CallsFoo can be instantiated?



is(T) is supposed to be false if T is not a valid type.

I would agree with you that the static assert should fail.

-Steve

is(some template instantiation) is true, but the actual instantiation fails

[Adrian Matoga via Digitalmars-d-learn]

Code:


struct HasFoo { void foo() {} }

struct NoFoo {}

struct CallsFoo(T) {
T t;
void bar() { t.foo(); }
}

static assert(is(CallsFoo!HasFoo));
alias Bar = CallsFoo!HasFoo;

static assert(is(CallsFoo!NoFoo)); // (1)
//alias Baz = CallsFoo!NoFoo;  // (2)


This compiles, although I expected that (1) should fail.
Now try uncommenting (2) and it can't be compiled.

Why does `is(CallsFoo!NoFoo)` evaluate to true if 
`is(CallsFoo!NoFoo)` can't be instantiated?

Am I missing something about `is(T)` or is it a bug?
How can I reliably test if CallsFoo can be instantiated?

InSituRegion + allocatorObject compile time error

[ref2401 via Digitalmars-d-learn]

Getting this error, could someone explain why?

void main(string[] args) {
InSituRegion!(1024) stackAlloc;
IAllocator alloc = allocatorObject(stackAlloc);
}

..\src\phobos\std\conv.d(5055):
Error: static assert  "Don't know how to initialize an object of 
type CAllocatorImpl!(InSituRegion!(1024u, 8u), cast(Flag)false) 
with arguments (InSituRegion!(1024u, 8u))"


..\src\phobos\std\experimental\allocator\package.d(1175):
instantiated from here: 
emplace!(CAllocatorImpl!(InSituRegion!(1024u, 8u), 
cast(Flag)false), InSituRegion!(1024u, 8u))


main.d(15):
instantiated from here: allocatorObject!(InSituRegion!(1024u, 8u))

Thank you

RC vibe.d 0.7.27-rc.2

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

Am 22.01.2016 um 12:14 schrieb Sönke Ludwig:

I've finally managed to tag a first beta for vibe.d. It contains
numerous optimizations in the network and HTTP code, so it's especially
important to thoroughly test this before release.

0.7.26 (except for the win32 driver) still compiles fine on DMD 2.070.0,
so a fully synchronized release is fortunately not essential this time.

http://code.dlang.org/packages/vibe-d/0.7.27-beta.1

Changelog:
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md


A release candidate is now up for testing. If now further issues come 
up, this will be tagged as 0.7.27 next week.


http://code.dlang.org/packages/vibe-d/0.7.27-rc.2

Re: reduce -> fold?

[Edwin van Leeuwen via Digitalmars-d]

On Friday, 29 January 2016 at 16:38:23 UTC, Brad Anderson wrote:
And just for completeness, here is monarchdodra's valiant but 
ultimately unsuccessful pull request which attempted fix 
reduce: 
https://github.com/D-Programming-Language/phobos/pull/861#issuecomment-20760448


Interestingly, that pull request links to another pull request 
which introduces fold, so we can just merge that one :) ?

https://github.com/D-Programming-Language/phobos/pull/2033

Re: Release D 2.070.0

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

On Friday, 29 January 2016 at 17:49:58 UTC, Nick Sabalausky wrote:
I don't recall: Does that parse the source for comments on its 
own or does it still use dmd's json (or html) output?


Does it on its own. (Well, except the search results page, it 
still uses the json, but I'm fixing that soon and the main body 
pages already do their own thing.)


Brian Schott's libdparse does the bulk of the work, independently 
of dmd. A big reason for this is that doing changes on dmd is a 
pain in the butt, and another one is that dmd is optimized toward 
compiling code (as it should be!) which isn't always ideal for 
doc generation (like version(Windows) docs being left out if you 
happen to be on a Linux box.)


So doing it myself frees me from dmd's design constraints as well 
as dmd's development process.

Re: Vision for the first semester of 2016

[Tofu Ninja via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


Just out of curiosity, is getting the different compilers in sync 
still a priority? Right now we have dmd at 2.070, ldc at 2.068. 
and gdc at 2.066.

Re: is(some template instantiation) is true, but the actual instantiation fails

[Adrian Matoga via Digitalmars-d-learn]

On Friday, 29 January 2016 at 16:36:01 UTC, Steven Schveighoffer 
wrote:

On 1/29/16 10:28 AM, Adrian Matoga wrote:

Code:


struct HasFoo { void foo() {} }

struct NoFoo {}

struct CallsFoo(T) {
 T t;
 void bar() { t.foo(); }
}

static assert(is(CallsFoo!HasFoo));
alias Bar = CallsFoo!HasFoo;

static assert(is(CallsFoo!NoFoo)); // (1)
//alias Baz = CallsFoo!NoFoo;  // (2)


This compiles, although I expected that (1) should fail.
Now try uncommenting (2) and it can't be compiled.

Why does `is(CallsFoo!NoFoo)` evaluate to true if 
`is(CallsFoo!NoFoo)`

can't be instantiated?
Am I missing something about `is(T)` or is it a bug?
How can I reliably test if CallsFoo can be instantiated?



is(T) is supposed to be false if T is not a valid type.

I would agree with you that the static assert should fail.

-Steve


Oh, there's more:
// this should fail:
static assert(is(CallsFoo!NoFoo));
// this should fail too:
static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return 
Baz.init; }(;

// and this:
static assert(__traits(compiles, { alias Baz = CallsFoo!NoFoo; 
return Baz.init; }()));

// but only this fails:
alias Baz = CallsFoo!NoFoo;

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

opApply @safety

[Chris Wright via Digitalmars-d-learn]

I want to create an opApply for a type.

I've marked my code @safe, because everything I wrote was @safe. The body 
of opApply is @safe, but it calls a delegate that may or may not be @safe.

How do I make it so I can iterate through this type safely and systemly?

I want to support iteration like:

foreach (string key, string value; collection) {}
foreach (size_t i, string key, string value; collection) {}

Re: D vs Rust

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 29 January 2016 at 15:39:53 UTC, bearophile wrote:
D is also more flexible (higher order templates, better CTFE, 
unrestricted UFCS, etc), and you can port Python or C code to D 
faster than to Rust.


So I think Rust targets a smaller number of coding purposes 
compared to D.


Which purposes and why?

Re: D vs Rust

[jmh530 via Digitalmars-d]

On Friday, 29 January 2016 at 12:05:08 UTC, Kagamin wrote:


Actually less. Without RAII you can't bind any realistic C++ 
library like Qt.


My understanding is that D has a lot of options for behavior 
similar to RAII, but it does not have the full capability. What 
would be the most important thing for D to change to improve the 
experience of binding to C++?

Re: Vision for the first semester of 2016

[Iain Buclaw via Digitalmars-d-announce]

On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
>>
>> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
>
>
> Just out of curiosity, is getting the different compilers in sync still a
priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.

If anyone wants to help out...

I have to also juggle working on GCC and GDB. :-)

When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect
it to stay there for a while...

Re: Release D 2.070.0

[Nick Sabalausky via Digitalmars-d-announce]

On 01/29/2016 11:09 AM, Adam D. Ruppe wrote:

On Thursday, 28 January 2016 at 19:46:48 UTC, Nick Sabalausky wrote:

Use dpldocs.info. We have good docs.


That's orthogonal to this.


It is just another example of why I feel it is necessary to take a
different direction than dmd.


I see. Good point. You've probably answered this elsewhere, but I don't 
recall: Does that parse the source for comments on its own or does it 
still use dmd's json (or html) output? Unless it does the parsing 100% 
on its own, then it would still suffer from the issue that PR addresses.

DMD 2.070.0 - The package is of bad quality

[Gary Willoughby via Digitalmars-d]

I get the following downloading and installing the Ubuntu x86_64 
deb file.


The package is of bad quality

The installation of a package which violates the quality 
standards isn't allowed. This could cause serious problems on 
your computer. Please contact the person or organisation who 
provided this package file and include the details beneath.


Lintian check results for 
/home/gary/Desktop/dmd_2.070.0-0_amd64.deb:
Can't close(GLOB(0xddf540)) filehandle: '' at 
/usr/share/lintian/helpers/coll/objdump-info-helper line 192
command failed with error code 123 at 
/usr/share/lintian/collection/objdump-info line 79.

warning: collect info objdump-info about package dmd failed
warning: skipping check of binary package dmd

Re: Vision for the first semester of 2016

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

On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:
In my perfect world, quality third party apps - as determined 
just by usage stats or something - would be automatically 
downloadable and their documentation searchable as if it was 
standard.


I've noticed that curated lists of libraries are popping up on 
github for various languages:

https://github.com/search?utf8=%E2%9C%93=awesome

If D gets more users maybe there would be a market for a 
commercial IDE with a reviewed repository with globally 
searchable reference documentation and cookbook recipes.


For popular languages stack overflow is pretty ok, but over time 
it is getting more chaotic.


Imagine an intelligent IDE that looks at the probability of a 
match between a cookbook recipe and what you type. A.I. 
templating of sorts.


Then the line between "standard library" and other library 
basically disappears.


I usually prefer to download from github for commercial code and 
put it in my project archive. I want to check out if the library 
programmers are maintaining it and have enough people as well. 
Then I lock that version until I find a reason to upgrade.


For me automatic downloading (dub etc) fits more with hobby 
projects and experiments.


While that isn't likely to happen, we could at least start 
promoting third party stuff more equally.


Yep, a curated list like those awesome-lists found on github 
would be a start.


Then write tutorials that only use libraries from that list.

This is a reason why I tend to only write libs that I actually 
use myself - at least then I know every function has one happy 
user.


Yeah, I find myself constantly wanting to improve on even the 
simplest libraries for better interaction with the kind of code 
the functions/objects seem to be most used with.


More of a discovery process of usability than "mathematical 
deduction".

Re: is(some template instantiation) is true, but the actual instantiation fails

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/29/16 6:44 PM, Basile B. wrote:


Haven't you seen my answer about constraint ?

If you put a constraint on your function template then invalid
instantiations are rejected. I mean... this language feature is not just
ornamental...

What do you think constraints are used for otherwise ^^


A constraint should not be necessary here. Constraints are useful when 
you have multiple templates that may match (without specializations), or 
you want to affect the way the compiler reports errors.


Iff a template instantiation T compiles, then is(T) should evaluate to 
true. At least, that's my understanding.


-Steve

Re: D vs Rust

[Joseph Rushton Wakeling via Digitalmars-d]

On Friday, 29 January 2016 at 18:43:19 UTC, Walter Bright wrote:

On 1/29/2016 7:39 AM, bearophile wrote:

[...]


Nice to see you back, bearophile!


Having not been around here much myself recently, I didn't even 
realize he was away, but ... agree :-)

Re: is(some template instantiation) is true, but the actual instantiation fails

[Basile B. via Digitalmars-d-learn]

On Friday, 29 January 2016 at 17:01:46 UTC, Adrian Matoga wrote:
On Friday, 29 January 2016 at 16:36:01 UTC, Steven 
Schveighoffer wrote:

On 1/29/16 10:28 AM, Adrian Matoga wrote:

[...]


is(T) is supposed to be false if T is not a valid type.

I would agree with you that the static assert should fail.

-Steve


Oh, there's more:
// this should fail:
static assert(is(CallsFoo!NoFoo));
// this should fail too:
static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return 
Baz.init; }(;

// and this:
static assert(__traits(compiles, { alias Baz = CallsFoo!NoFoo; 
return Baz.init; }()));

// but only this fails:
alias Baz = CallsFoo!NoFoo;

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


Haven't you seen my answer about constraint ?

If you put a constraint on your function template then invalid 
instantiations are rejected. I mean... this language feature is 
not just ornamental...


What do you think constraints are used for otherwise ^^

Re: UTF-16 endianess

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/29/16 6:03 PM, Marek Janukowicz wrote:

On Fri, 29 Jan 2016 17:43:26 -0500, Steven Schveighoffer wrote:

Is there anything I should know about UTF endianess?


It's not any different from other endianness.

In other words, a UTF16 code unit is expected to be in the endianness of
the platform you are running on.

If you are on x86 or x86_64 (very likely), then it should be little endian.

If your source of data is big-endian (or opposite from your native
endianness),


To be precise - my case is IMAP UTF7 folder name encoding and I finally found
out it's indeed big endian, which explains my problem (as I'm indeed on x86_64).


it will have to be converted before treating as a wchar[].


Is there any clever way to do the conversion? Or do I need to swap the bytes
manually?


No clever way, just the straightforward way ;)

Swapping endianness of 32-bits can be done with core.bitop.bswap. Doing 
it with 16 bits I believe you have to do bit shifting. Something like:


foreach(ref elem; wcharArr) elem = ((elem << 8) & 0xff00) | ((elem >> 8) 
& 0x00ff);


Or you can do it with the bytes directly before casting




Note the version identifiers BigEndian and LittleEndian can be used to
compile the correct code.


This solution is of no use to me as I don't want to change the endianess in
general.


What I mean is that you can annotate your code with version statements like:

version(LittleEndian)
{
   // perform the byteswap
   ...
}

so your code is portable to BigEndian systems (where you would not want 
to byte swap).


-Steve

Re: Relocatable objects and internal pointers

[H. S. Teoh via Digitalmars-d-learn]

On Sat, Jan 30, 2016 at 01:21:27AM +, Matt Elkins via Digitalmars-d-learn 
wrote:
> On Saturday, 30 January 2016 at 01:18:33 UTC, Ali Çehreli wrote:
> >Definitely so. Rvalues are moved around all the time. The following
> >program has two rvalue moves without calling post-blits or
> >destructors.
> 
> Oi, that makes life tough. Ok, I'll figure something else out, then...
[...]

Keep in mind that D structs are conceptually different from C++ structs
(even if they are similarly implemented). D structs are supposed to be
value types with POD-like semantics; so when passing structs around they
are bit-copied into the destination and then the postblit method
(this(this)) is called to "patch up" the copy. This is unlike in C++
where you have copy ctors and dtors and operator=() to manage copying.

Because there are no copy ctors, having internal pointers can be
dangerous, since structs can move around in memory without any warning
(e.g., returning a struct from a function generally involves copying it
from the callee's stack frame into a local variable in the caller's
stack frame).

If you need something with internal pointers, you might want to consider
classes instead. Either that, or be sure to allocate your structs on the
heap instead, and work with pointers instead of the struct values
directly. (Note that this is still risky, since somebody might
dereference the pointer and get a stack copy of the struct, which will
cause problems when it then gets passed around.)


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom

Re: Relocatable objects and internal pointers

[Matt Elkins via Digitalmars-d-learn]

On Saturday, 30 January 2016 at 01:28:54 UTC, H. S. Teoh wrote:
On Sat, Jan 30, 2016 at 01:21:27AM +, Matt Elkins via 
Digitalmars-d-learn wrote:
On Saturday, 30 January 2016 at 01:18:33 UTC, Ali Çehreli 
wrote:
>Definitely so. Rvalues are moved around all the time. The 
>following program has two rvalue moves without calling 
>post-blits or destructors.


Oi, that makes life tough. Ok, I'll figure something else out, 
then...

[...]

Keep in mind that D structs are conceptually different from C++ 
structs (even if they are similarly implemented). D structs are 
supposed to be value types with POD-like semantics; so when 
passing structs around they are bit-copied into the destination 
and then the postblit method (this(this)) is called to "patch 
up" the copy. This is unlike in C++ where you have copy ctors 
and dtors and operator=() to manage copying.


Because there are no copy ctors, having internal pointers can 
be dangerous, since structs can move around in memory without 
any warning (e.g., returning a struct from a function generally 
involves copying it from the callee's stack frame into a local 
variable in the caller's stack frame).


If you need something with internal pointers, you might want to 
consider classes instead. Either that, or be sure to allocate 
your structs on the heap instead, and work with pointers 
instead of the struct values directly. (Note that this is still 
risky, since somebody might dereference the pointer and get a 
stack copy of the struct, which will cause problems when it 
then gets passed around.)



T


Yeah, but the whole point of what I am doing is to avoid using 
the heap; I can think of several ways to implement this if I 
relax that restriction :). I'm basically trying to make C++'s 
std::unique_ptr for resource handles, a thin wrapper which 
ensures resource cleanup and allows moving the handle. Since I'm 
putting it in my lowest-level/most-generic library with no 
visibility on how it gets used, I want it very lightweight 
(ideally zero-cost, like I can do in C++11, or at least low-cost 
[sans heap] like I could do in C++98) so that I can use it with 
the broadest range of higher-level applications.

Re: Relocatable objects and internal pointers

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/29/16 8:07 PM, Matt Elkins wrote:

[snip]
on D and came across a section in TDPL which said internal pointers are
verboten because objects must be relocatable. Does this mean my example
is invalid (e.g., the invariant will not hold in all circumstances)? If
it is invalid, does that mean there are circumstances under which the
post-blit constructor can be elided when performing a copy or copy-like
operation (such as a move)? I've been treating it like a sort of
copy-constructor that lacks visibility on the copied-from object, but
maybe that's a mistake...


No, you cannot have internal pointers. But...

I figured out a way to have them. You just have to guarantee you don't 
copy the actual "pointer" out of the struct:


https://forum.dlang.org/post/mk5k4l$s5r$1...@digitalmars.com

-Steve

Re: reduce -> fold?

[Vladimir Panteleev via Digitalmars-d]

On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote:
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu 
wrote:
So the next best solution is to introduce a new name such as 
the popular "fold", and put them together in the documentation.


Just to bikeshed a little, I remember that when I first started 
using std.algorithm I was ctrl-F'ing for "accumulate" and not 
finding it quite often. D competes with C++ directly, so do 
consider that name :-)


I'm not sure what the problem was, but the documentation for 
"reduce" already mentions "accumulate":


https://dlang.org/library/std/algorithm/iteration/reduce.html

UTF-16 endianess

[Marek Janukowicz via Digitalmars-d-learn]

I have trouble understanding how endianess works for UTF-16.

For example UTF-16 code for 'ł' character is 0x0142. But this program shows
otherwise:

import std.stdio;

public void main () {
  ubyte[] properOrder = [0x01, 0x42];
ubyte[] reverseOrder = [0x42, 0x01];
writefln( "proper: %s, reverse: %s", 
cast(wchar[])properOrder, 
cast(wchar[])reverseOrder );
}

output:

proper: 䈁, reverse: ł

Is there anything I should know about UTF endianess?

-- 
Marek Janukowicz

Trouble complinig DMD 2.070 on windows

[E.S. Quinn via Digitalmars-d]

I'm trying to compile a 64-bit DMD.exe on windows (as my project 
has enough CTFE and Template work that it bumps up against the 
4gb limit).


with the pre-DDMD setup I was just able to load the thing up in 
visual studio 2013 and build, but I've been having some 
difficulty with 2.070's projects. Namely, it seems that no matter 
what type of bulid I do, I get a bunch of errors in elfobj.c and 
one in filename.d


Error	1	error C3861: 'assert': identifier not 
found	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3512	1	dmd_backend
Error	2	error C3861: 'assert': identifier not 
found	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3527	1	dmd_backend
Error	3	error C2352: 'Obj::reftoident' : illegal call of 
non-static member 
function	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3528	1	dmd_backend
Error	4	error C2065: 'symtab_strings' : undeclared 
identifier	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3531	1	dmd_backend
Error	5	error C2227: left of '->size' must point to 
class/struct/union/generic 
type	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3531	1	dmd_backend
Error	6	error C2065: 'symtab_strings' : undeclared 
identifier	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3532	1	dmd_backend
Error	7	error C2227: left of '->writeString' must point to 
class/struct/union/generic 
type	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3532	1	dmd_backend
Error	8	error C2065: 'symtab_strings' : undeclared 
identifier	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3533	1	dmd_backend
Error	9	error C2227: left of '->setsize' must point to 
class/struct/union/generic 
type	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3533	1	dmd_backend
Error	10	error C2227: left of '->size' must point to 
class/struct/union/generic 
type	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3533	1	dmd_backend
Error	11	error C2065: 'symtab_strings' : undeclared 
identifier	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3534	1	dmd_backend
Error	12	error C2227: left of '->writeString' must point to 
class/struct/union/generic 
type	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3534	1	dmd_backend
Error	13	error C3861: 'elf_addsym': identifier not 
found	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3536	1	dmd_backend
Error	14	error C3861: 'MAP_SEG2SECIDX': identifier not 
found	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3536	1	dmd_backend
Error	15	error C2352: 'Obj::reftoident' : illegal call of 
non-static member 
function	D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3542	1	dmd_backend
Error	16	Error: function ddmd.root.filename.GetFullPathNameA 
(const(wchar)* lpFileName, uint nBufferLength, wchar* lpBuffer, 
wchar** lpFilePart) is not callable using argument types 
(const(char)*, int, typeof(null), 
typeof(null))	D:\programs\dmd\dmd2\src\dmd\root\filename.d	645	
	17	IntelliSense: identifier "assert" is 
undefined	d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3512	5	dmd_backend
	18	IntelliSense: a nonstatic member reference must be relative 
to a specific 
object	d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3528	13	dmd_backend
	19	IntelliSense: identifier "symtab_strings" is 
undefined	d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3531	29	dmd_backend
	20	IntelliSense: identifier "elf_addsym" is 
undefined	d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3536	30	dmd_backend
	21	IntelliSense: identifier "MAP_SEG2SECIDX" is 
undefined	d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3536	79	dmd_backend
	22	IntelliSense: a nonstatic member reference must be relative 
to a specific 
object	d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c	3542	9	dmd_backend


(If this is an actual issue with the code or projects I'll file a 
bug, but I wanted to make sure it wasn't just me doing something 
wrong first)

Re: opApply @safety

[Basile B. via Digitalmars-d-learn]

On Friday, 29 January 2016 at 17:44:34 UTC, Chris Wright wrote:

I want to create an opApply for a type.

I've marked my code @safe, because everything I wrote was 
@safe. The body of opApply is @safe, but it calls a delegate 
that may or may not be @safe.


How do I make it so I can iterate through this type safely and 
systemly?


I want to support iteration like:

foreach (string key, string value; collection) {}
foreach (size_t i, string key, string value; collection) {}


You can implement an input range and annotate all the primitives 
as @safe.
Then if there's only an input range in your agregate, DMD will 
auto-detect that it must use it in foreach():


http://dlang.org/spec/statement.html#foreach-with-ranges

in the worst case (range not implementable directly but only as a 
getter in .range() or .opSlice() you'll have to change the style 
a bit and consume the range explicitly in a typical "while 
(!stuff.empty) {...}"

Re: UTF-16 endianess

[Johannes Pfau via Digitalmars-d-learn]

Am Fri, 29 Jan 2016 18:58:17 -0500
schrieb Steven Schveighoffer :

> On 1/29/16 6:03 PM, Marek Janukowicz wrote:
> > On Fri, 29 Jan 2016 17:43:26 -0500, Steven Schveighoffer wrote:  
> >>> Is there anything I should know about UTF endianess?  
> >>
> >> It's not any different from other endianness.
> >>
> >> In other words, a UTF16 code unit is expected to be in the
> >> endianness of the platform you are running on.
> >>
> >> If you are on x86 or x86_64 (very likely), then it should be
> >> little endian.
> >>
> >> If your source of data is big-endian (or opposite from your native
> >> endianness),  
> >
> > To be precise - my case is IMAP UTF7 folder name encoding and I
> > finally found out it's indeed big endian, which explains my problem
> > (as I'm indeed on x86_64). 
> >> it will have to be converted before treating as a wchar[].  
> >
> > Is there any clever way to do the conversion? Or do I need to swap
> > the bytes manually?  
> 
> No clever way, just the straightforward way ;)
> 
> Swapping endianness of 32-bits can be done with core.bitop.bswap.
> Doing it with 16 bits I believe you have to do bit shifting.
> Something like:
> 
> foreach(ref elem; wcharArr) elem = ((elem << 8) & 0xff00) | ((elem >>
> 8) & 0x00ff);
> 
> Or you can do it with the bytes directly before casting


There's also a phobos solution: bigEndianToNative in std.bitmanip.

[Issue 15623] is(M!N) evaluates to true for M!N that fails to instantiate.

[via Digitalmars-d-bugs]

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

Ali Cehreli  changed:

   What|Removed |Added

 CC||acehr...@yahoo.com

--- Comment #1 from Ali Cehreli  ---
Interestingly, they all fail when moved inside a function. So, they seem to be
broken only at module scope.

--

Re: Relocatable objects and internal pointers

[Ali Çehreli via Digitalmars-d-learn]

On 01/29/2016 05:07 PM, Matt Elkins wrote:

>  this(/* arguments to populate stuff */)
>  {
>  m_this = 
>  /* ... populate stuff ... */
>  }

> a section in TDPL which said internal pointers are
> verboten because objects must be relocatable. Does this mean my example
> is invalid

Yes, D explicitly bans internal pointers.

> does that mean there are circumstances under which the
> post-blit constructor can be elided when performing a copy or copy-like
> operation (such as a move)?

Definitely so. Rvalues are moved around all the time. The following 
program has two rvalue moves without calling post-blits or destructors.


struct Foo {
this(this) {
assert(false);// not expected to be called in this program
}
}

Foo makeFoo() {
return Foo();
}

void takesFoo(Foo foo) {
}

void main() {
Foo foo;
foo = makeFoo();// post-blit not called
takesFoo(Foo());// post-blit not called
}

Ali

Re: Dub packages: Best practices for windows support

[Mike Parker via Digitalmars-d-learn]

On Friday, 29 January 2016 at 19:46:40 UTC, Johannes Pfau wrote:

Now on windows, things are more complicated. First of all, I 
can't seem

to simply use "libs": ["foo"] as the linker won't find the C
import .lib file. Then apparently there's no way to add a 
library search

path with the MSVC linker? So I have to use the full path:
"libs": [$PACKAGE_DIR\\path\\foo]. Without $PACKAGE_DIR paths 
are
incorrect for applications using the library because of a dub 
problem.
And then I'll have to use different import libraries and paths 
for -m32,

-m64 and -m32mscoff.


Now you know my motivation for creating Derelict.



All this leads to the following questions:
* Should cairoD copy the DLLs for all applications using 
cairoD? This
  way simply adding a dependency will work. However, if users 
want to
  use a self compiled cairo DLL with fewer dependencies there's 
no easy

  way to disable the file copying?
* Should cairoD link in the .lib DLL import file? This might be 
useful
  even when not copying the DLLs. But if users want to link a 
custom
  import library that would be difficult. OTOH not copying DLLs 
and/or

  not linking the import library will make dub.json much more
  complicated for simple applications, especially if these 
applications

  want to support -m32, -m32mscoff and -m64.


IMO, no to both of these (for now). Including all of these 
dependencies is going to mean that all of your users, no matter 
the platform, will pull the down with every new version of gtkd.  
I recommend you provide all of the precompiled DLLs and import 
libraries as a separate download and let the user do the 
configuration needed to get it to link. Most Windows developers 
are used to it. You can provide instructions for those who aren't.


Hopefully one day dub will have the ability to pull down library 
dependencies on demand, or based on the current platform and 
architecture by default, then this problem goes away.


* What's the best way to support all of -m32, -m32mscoff and 
-m64? I've
  got working import libraries and DLLs for all configurations, 
but how
  to support this in dub.json? I think the best way would be to 
have
  -ms32coff as a special architecture or flag for dub, but I 
can't seem
  to find any documentation about that. -m64 can be detected by 
x86_64

  in platforms, but how to detect -m32 vs -m32mscoff?

  Alternatively I could simply let users choose the 
configurations

  manually. But adding dflags: ["-m32mscoff"] does not build the
  Derelict dependencies with the m32mscoff flag so linking will 
fail...


  DFLAGS="-m32mscoff" doesn't work with dub test as the dub test
  command ignores the DFLAGS variable. I'd have to check 
whether it
  works for applications, but then there's still no way to use 
the

  correct cairo import library in cairoDs dub.json


There's an issue for this at [1]. Until support for -m32mscoff is 
baked in, distributing any libraries with a dub project will be 
problematic.

Re: Dub packages: Best practices for windows support

[Mike Parker via Digitalmars-d-learn]

On Saturday, 30 January 2016 at 01:17:13 UTC, Mike Parker wrote:

There's an issue for this at [1]. Until support for -m32mscoff 
is baked in, distributing any libraries with a dub project will 
be problematic.


[1] https://github.com/D-Programming-Language/dub/issues/628

Re: Dub packages: Best practices for windows support

[Mike Parker via Digitalmars-d-learn]

On Saturday, 30 January 2016 at 01:17:13 UTC, Mike Parker wrote:

Hopefully one day dub will have the ability to pull down 
library dependencies on demand, or based on the current 
platform and architecture by default, then this problem goes 
away.



I should say "precompiled library dependencies".

Re: reduce -> fold?

[deadalnix via Digitalmars-d]

On Friday, 29 January 2016 at 23:45:04 UTC, Ola Fosheim Grøstad 
wrote:

So D is adding currying and builtin tuples? :^)


Yes. Come back in 10 years it'll be ready for you.

Re: Autocompletion not working on Xamarin Studio for D

[nbro via Digitalmars-d]

On Friday, 29 January 2016 at 21:31:35 UTC, Pradeep Gowda wrote:

On Friday, 29 January 2016 at 21:05:00 UTC, nbro wrote:

Hi!

I am trying to write some code in D using Xamarin Studio, but 
it's not autocompleting the code as I would expect. For 
example, it does not even gives you autocompletion for 
libraries, but apparently only for the language's primitives, 
i.e. keywords, etc. Is this the expected behaviour or is 
there's something wrong with my settings?


Thanks!


I wrote this up https://www.btbytes.com/posts/xamarind.html 
(Xamarin Studio with auto completion etc., for D on Mac)


HTH.


Yes, I was forgetting to include the link the libraries. I hadn't 
use Xamarin for a while and I remembered I had to set up Xamarin 
for D, but meanwhile I removed the D compiler, updated Xamarin, 
etc, and it might be that these settings were reset.

Re: UTF-16 endianess

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

On Friday, 29 January 2016 at 22:36:37 UTC, Marek Janukowicz 
wrote:

I have trouble understanding how endianess works for UTF-16.


UTF-16 (as well as UTF-32) comes in both little-endian and 
big-endian variants. A byte-order marker in the file can help you 
detect which one it is in.


See t his t able:

http://www.unicode.org/faq/utf_bom.html#gen6

The Quick Mom Algorithm

[Andrei Alexandrescu via Digitalmars-d]

http://dpaste.dzfl.pl/05a82699acc8

So over the past few days I've been in the zone working on a smooth 
implementation of "Median of Medians" 
(https://en.wikipedia.org/wiki/Median_of_medians). Its performance is 
much better compared to the straightforward implementation. However, in 
practice it's very hard to get it to beat simple heuristics (such as 
median of five, random pivot etc). These heuristics run `n` comparisons 
for an input of length `n`, whereas the MoM needs over twice as many 
comparisons. Also it does a bunch of swapping around the data. Overall I 
got it within 2.5x of the heuristic-based topN for most data sizes up to 
tens of millions.


While thinking of MoM and the core reasons of its being slow (adds nice 
structure to its input and then "forgets" most of it when recursing), I 
stumbled upon a different algorithm. It's much simpler, also 
deterministic and faster than MoM for many (most?) inputs. But it's not 
guaranteed to be linear. After having pounded at this for many hours, it 
is clear that I am in need of some serious due destruction. I call it a 
"quick median of medians" or in short "quick mom".


Consider the algorithm defined as follows over a range `r` of length 
`n`. It returns an index to an element likely to be in the second 
tertile of r. (A tertile is a third of the range. So the expectation is 
that the returned index x is such that e<=r[x] for at least one third of 
the range, and r[x]<=e again for at least one third of the range.)


0. If n<=3, compute median by rote and return its index.

1. Divide r in three equal adjacent subranges r0 = r[0 .. $/3], r1 = 
r[$/3 .. $*2/3], r2 = r[$*2/3 .. $].


2. Recurse to get the median of these three, call them m0, m1, m2.

3. Return the median of m0, m1, m2.

Note that no data has been written yet; we only have an estimate of a 
pivot. On random inputs it's expected that the median thus gotten is 
greater than 1/6 + 1/6 = 1/3 elements, and less than the same fraction.


The algorithm completes in linear time.

However, the pivot obtained is just an approximation. In the worst case 
it's possible that e.g. all recursions return the leftmost of the 
allowed index, so the bound deteriorates by 1/3 for each recursion 
depth, or generally to (1/3)^^log3(n).


Not good! That's where the quick mom pays attention. After it partitions 
the data using the pivot obtained by the quick mom method, the 
partitioning stage checks whether the resulting pivot falls within 
bounds. If not, it runs a precise selection method (such as proper 
median of medians - "thorough mom") to bring the pivot where it needs to 
be. The data patterns that cause the quick mom to fail systematically 
are rather odd but worst case is what it is.


Overall the partitioning either succeeds with the quick mom pivot in 
linear time, or does one more linear pass if "unlucky". So overall 
partition is linear. (Micro-optimization: not all data needs to be 
repartitioned, only that outside the not-so-good pivot.) Unlike the 
quick mom, the partition guarantees a pivot in the mid tertile.


After partitioning the classic quickselect algorithm may be implemented.

There's one more _really_ juicy detail. In fact, the quick mom may 
finish without looking at all data. Look at the implementation - there 
are two overloads of quickMom. The second gets the bounds and works as 
follows: if you've already computed two elements of a median, the third 
may be chosen only if in between the two. Otherwise, you only care 
whether it's larger or smaller than the other two. This allows the 
algorithm to finish certain recursion branches early.



Destroy!

Andrei

Re: reduce -> fold?

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 29 January 2016 at 23:20:38 UTC, Walter Bright wrote:

On 1/29/2016 5:11 AM, Luís Marques wrote:
Just to bikeshed a little, I remember that when I first 
started using
std.algorithm I was ctrl-F'ing for "accumulate" and not 
finding it quite often.

D competes with C++ directly, so do consider that name :-)


For algorithms and FP in general, we may be better off drawing 
inspiration from Haskell, as C++ does not have FP in its DNA.


So D is adding currying and builtin tuples? :^)

To cast a uint to float to compute k/n, use to! or cast()?

[Enjoys Math via Digitalmars-d-learn]

I want to compute the points of a regular polygon in a loop:

float r = 1.0;

for (uint k=0; k < numVerts; k++) {
   vertlist ~= Vec2D(r * cos(k/n * 2 * PI), ...)
}

How do I make sure k/n is a float or double?

Re: is(some template instantiation) is true, but the actual instantiation fails

[Ali Çehreli via Digitalmars-d-learn]

On 01/29/2016 09:01 AM, Adrian Matoga wrote:

> Oh, there's more:
> // this should fail:
> static assert(is(CallsFoo!NoFoo));
> // this should fail too:
> static assert(is(typeof({ alias Baz = CallsFoo!NoFoo; return Baz.init;
> }(;
> // and this:
> static assert(__traits(compiles, { alias Baz = CallsFoo!NoFoo; return
> Baz.init; }()));
> // but only this fails:
> alias Baz = CallsFoo!NoFoo;
>
> https://issues.dlang.org/show_bug.cgi?id=15623

As I noted on the bug report, they are work when moved from module scope 
to inside a function (e.g. main()). At least there's that workaround...


Ali

Re: opApply @safety

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/29/16 3:08 PM, Chris Wright wrote:

On Fri, 29 Jan 2016 14:00:08 -0500, Steven Schveighoffer wrote:


On 1/29/16 12:44 PM, Chris Wright wrote:

I want to create an opApply for a type.

I've marked my code @safe, because everything I wrote was @safe. The
body of opApply is @safe, but it calls a delegate that may or may not
be @safe.

How do I make it so I can iterate through this type safely and
systemly?


Likely an overload. Tag the delegate as being @safe or not.

-Steve


That's handy. It works. I can make it so someone can call:
foo.opApply((i, k, v) @safe => 0);
foo.opApply((i, k, v) @system => 0);

And that works.

However, if you have:
@safe void bar() {
   foreach(i, k, v; foo) {
   }
}

the compiler complains:

opapplysafe.d(12): Error: foo.opApply matches more than one declaration:
opapplysafe.d(2): @safe int(int delegate(int, string, string) @safe
dg)
and:
opapplysafe.d(5): @system int(int delegate(int, string, string)
@system dg)

Guess I'll file a bug.



Definitely seems like a bug.

As a workaround, you can name the opApply functions:

struct S
{
   int opApply(int delegate(int, string, string) @safe dg) @safe {...}
   int unsafeApply(int delegate(int, string, string) dg) {...}
}

foreach(i, k, v; foo.unsafeApply) {...}

though that's... ugly.

-Steve

Re: opApply @safety

[Chris Wright via Digitalmars-d-learn]

On Fri, 29 Jan 2016 23:35:35 +, Basile B. wrote:
> You can implement an input range and annotate all the primitives as
> @safe.

I hadn't realized that if front() returns a tuple, it's automatically 
expanded. Works for me.

Re: DMD 2.070.0 - The package is of bad quality

[Zekereth via Digitalmars-d]

On Friday, 29 January 2016 at 17:38:18 UTC, Gary Willoughby wrote:
I get the following downloading and installing the Ubuntu 
x86_64 deb file.


The package is of bad quality

The installation of a package which violates the quality 
standards isn't allowed. This could cause serious problems on 
your computer. Please contact the person or organisation who 
provided this package file and include the details beneath.


Lintian check results for 
/home/gary/Desktop/dmd_2.070.0-0_amd64.deb:
Can't close(GLOB(0xddf540)) filehandle: '' at 
/usr/share/lintian/helpers/coll/objdump-info-helper line 192
command failed with error code 123 at 
/usr/share/lintian/collection/objdump-info line 79.

warning: collect info objdump-info about package dmd failed
warning: skipping check of binary package dmd


Not much help but I downloaded it last night and it worked fine 
with Linux Mint.

Re: To cast a uint to float to compute k/n, use to! or cast()?

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/29/16 6:48 PM, Enjoys Math wrote:

I want to compute the points of a regular polygon in a loop:

float r = 1.0;

for (uint k=0; k < numVerts; k++) {
vertlist ~= Vec2D(r * cos(k/n * 2 * PI), ...)
}

How do I make sure k/n is a float or double?


uint is promoted to float/double with a binary math operation. You could 
simply reverse the order of your expression:


2 * PI * k/n

But if you want to force a type change with simple conversions such as 
these, just use a constructor:


float(k) / n * 2 * PI

There is no need to cast or use `to` (though both of those would be 
equivalent to simple conversion).


-Steve

Re: UTF-16 endianess

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/29/16 5:36 PM, Marek Janukowicz wrote:

I have trouble understanding how endianess works for UTF-16.

For example UTF-16 code for 'ł' character is 0x0142. But this program shows
otherwise:

import std.stdio;

public void main () {
   ubyte[] properOrder = [0x01, 0x42];
ubyte[] reverseOrder = [0x42, 0x01];
writefln( "proper: %s, reverse: %s",
cast(wchar[])properOrder,
cast(wchar[])reverseOrder );
}

output:

proper: 䈁, reverse: ł

Is there anything I should know about UTF endianess?


It's not any different from other endianness.

In other words, a UTF16 code unit is expected to be in the endianness of 
the platform you are running on.


If you are on x86 or x86_64 (very likely), then it should be little endian.

If your source of data is big-endian (or opposite from your native 
endianness), it will have to be converted before treating as a wchar[].


Note the version identifiers BigEndian and LittleEndian can be used to 
compile the correct code.


-Steve

Re: reduce -> fold?

[Walter Bright via Digitalmars-d]

On 1/29/2016 5:11 AM, Luís Marques wrote:

Just to bikeshed a little, I remember that when I first started using
std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite often.
D competes with C++ directly, so do consider that name :-)


For algorithms and FP in general, we may be better off drawing inspiration from 
Haskell, as C++ does not have FP in its DNA.

Relocatable objects and internal pointers

[Matt Elkins via Digitalmars-d-learn]

Hi all, I'm a C++ programmer trying to decide whether to switch 
my main focus to D, and so I'm working on a pet project using it. 
So far I really like some of the practical aspects of the 
language (built-in contracts are great, the metaprogramming is 
very accessible, and I can't enough of these compile speeds!), 
but I keep finding myself frustrated by what seem like 
expressiveness limitations (unless, as I hope, they are just 
examples of my newbieness shining through). Case in point:


In an attempt to work around one apparent limitation (previously 
asked about here 
http://forum.dlang.org/thread/eizmagtimvetogana...@forum.dlang.org) I came up with an idea which would require storing internal points in a struct. A very stripped-down but illustrative example would be something like this:


[code]
struct Foo
{
invariant
{
assert(m_this == );
}

@disable(this);

this(/* arguments to populate stuff */)
{
m_this = 
/* ... populate stuff ... */
}

this(this)
{
m_this = 
/* ... do more stuff ... */
}

private:
Foo* m_this;
/* ... stuff ... */
}
[/code]

This is just a piece of what I am doing, if you are wondering why 
I am bothering to save a pointer to this. However, I was doing 
some reading on D and came across a section in TDPL which said 
internal pointers are verboten because objects must be 
relocatable. Does this mean my example is invalid (e.g., the 
invariant will not hold in all circumstances)? If it is invalid, 
does that mean there are circumstances under which the post-blit 
constructor can be elided when performing a copy or copy-like 
operation (such as a move)? I've been treating it like a sort of 
copy-constructor that lacks visibility on the copied-from object, 
but maybe that's a mistake...

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Friday, 29 January 2016 at 23:41:47 UTC, Ola Fosheim Grøstad 
wrote:




Yep, a curated list like those awesome-lists found on github 
would be a start.




I've got one before there were many awesome-lists: 
https://github.com/zhaopuming/awesome-d

Re: Relocatable objects and internal pointers

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/29/16 9:35 PM, Matt Elkins wrote:

On Saturday, 30 January 2016 at 02:09:55 UTC, Steven Schveighoffer wrote:

I figured out a way to have them. You just have to guarantee you don't
copy the actual "pointer" out of the struct:

https://forum.dlang.org/post/mk5k4l$s5r$1...@digitalmars.com


Unfortunately, that won't work for what I was trying to do. The stuff I
elided in the comments were more pointers to other Foo instances, used
to create a linked-list (of stack-allocated objects); these would still
break under the conditions Ali described. I was only storing the this
pointer so that blitted objects could deduce where they came from
(trying to turn the post-blit constructor into a copy-constructor).


Ah, so you were actually counting on the postblit to have an *invalid* 
pointer to begin with :) Yeah, that isn't going to work. In D, it's 
legal to do something like memcpy struct data (with no postblit), and 
this is done quite often in many places because of that.



Thanks, though. I'm thinking that maybe D just can't express these
semantics without substantial overhead. While somewhat disappointing (I
came into D with stars in my eyes :)), it's not enough by itself to make
me go back to C++, at least not just yet. Not when I can just use a few
static ifs to do what previously required careful template crafting that
I wouldn't understand 3 months later. On the other hand, I'm falling
behind on my library books since I no longer have any time for reading
during compilations ;).


There are some really smart people who frequent these forums, if you 
post your actual use case, you may get an answer that you hadn't thought of.


I saw you were trying to implement something like std::unique_ptr? There 
is http://dlang.org/phobos/std_typecons.html#.Unique


Not sure if it helps.

-Steve