Re: `clear`ing a dynamic array

[anonymous via Digitalmars-d-learn]

On 24.10.2015 15:18, Shriramana Sharma wrote:

   int a[] = [1,2,3,4,5];


Aside: `int[] a;` is the preferred style for array declarations.


How to make it so that after clearing `a`, `b` will also point to the same
empty array? IOW the desired output is:

[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[]

... and any further items added to `a` should also reflect in `b`.



You can't do that with built-in arrays. The length of a dynamic array is 
a value member of the array structure. So to update `b`'s length you 
need access to the actual `b`.

Re: `clear`ing a dynamic array

[Cauterite via Digitalmars-d-learn]

I'm afraid what you're asking for is impossible. Because 'a' and 
'b' are both slices, they each have their own 'length' field. 
When you do 'a = []', you're effectively doing 'a.length = 0'. 
There's no way to change 'b.length' through 'a'. To get that 
effect, you'd have to do something like this:

int[] a = [1,2,3,4,5];
int[]* b = 
a = [];
assert(*b == [] && b.length == 0);

On Saturday, 24 October 2015 at 13:18:26 UTC, Shriramana Sharma 
wrote:
Hello. I had first expected that dynamic arrays (slices) would 
provide a `.clear()` method but they don't seem to. Obviously I 
can always effectively clear an array by assigning an empty 
array to it, but this has unwanted consequences that `[]` 
actually seems to allocate a new dynamic array and any other 
identifiers initially pointing to the same array will still 
show the old contents and thus it would no longer test true for 
`is` with this array. See the following code:


import std.stdio;
void main()
{
  int a[] = [1,2,3,4,5];
  int b[] = a;
  writeln(a);
  writeln(b);
  //a.clear();
  a = [];
  writeln(a);
  writeln(b);
}

which outputs:

[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[1, 2, 3, 4, 5]

How to make it so that after clearing `a`, `b` will also point 
to the same empty array? IOW the desired output is:


[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[]

... and any further items added to `a` should also reflect in 
`b`.

Re: LDC iOS cross-compiler with arm64

[Dan Olson via Digitalmars-d-announce]

Jacob Carlborg  writes:

> On 2015-10-24 12:01, Suliman wrote:
>
>> Would it be hard to add Windows/Linux host available? Would it be hard
>> to develop iOS apps on Windows in comparison of using MacOSX?
>
> It depends on what you mean. Microsoft already supports developing iOS
> apps on Windows, but the building is actually performed on OS X.

In addition, the LDC cross-compiler could be built with a few tweaks for
any build host that LDC already supports.  If someone already has a
Windows/Linux dev environment for iOS, then LDC could be used with it.

Re: Array of templated classes or structs

[qsdfghjk via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 15:57:09 UTC, Dandyvica wrote:

Hi guys,

Apart from deriving from the same class and declaring an array 
of that

root class, is there a way to create an array of templates?

This seems not possible since template are compile-time 
generated, but just to be sure. For example, it seems logical 
to get an array of complex numbers but Complex needs to be 
declared with a type.


Thanks for any hint.


You can declare an array whose the element type matches to one of 
the template parameter:


---
struct Foo(T)
{
Foo!T[] foos;
// typeof(this)[] foos // equivalent
}
---

since it's an array (fixed size whatever is the element type: 
size_t len + size_t pointer) it doesn't matter if the template 
declaration is partial.

Re: Converting Unicode Escape Sequences to UTF-8

[Nordlöw via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 08:54:40 UTC, Nordlöw wrote:

Working first version at

https://github.com/nordlow/justd/blob/master/conv_ex.d#L207

Next I'll make it a range.


Made it a range:

https://github.com/nordlow/justd/blob/master/conv_ex.d#L207

Re: `clear`ing a dynamic array

[rsw0x via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 13:18:26 UTC, Shriramana Sharma 
wrote:
Hello. I had first expected that dynamic arrays (slices) would 
provide a `.clear()` method but they don't seem to. Obviously I 
can always effectively clear an array by assigning an empty 
array to it, but this has unwanted consequences that `[]` 
actually seems to allocate a new dynamic array and any other 
identifiers initially pointing to the same array will still 
show the old contents and thus it would no longer test true for 
`is` with this array. See the following code:


[...]


use std.container.array

Re: LDC iOS cross-compiler with arm64

[Dan Olson via Digitalmars-d-announce]

extrawurst  writes:

> On Saturday, 24 October 2015 at 07:07:18 UTC, Dan Olson wrote:
>> This is another set of binaries and universal libs for the
>> experimental LDC iOS cross-compiler.  It is now based on LDC 0.15.2
>> (2.066.1) and LLVM 3.6.1.
>>
>> [...]
>
> Cool work!
>
> Can this be merged with official LDC eventually ?
>
> --Stephan

Yes, that is the plan.

Array of templated classes or structs

[Dandyvica via Digitalmars-d-learn]

Hi guys,

Apart from deriving from the same class and declaring an array of 
that

root class, is there a way to create an array of templates?

This seems not possible since template are compile-time 
generated, but just to be sure. For example, it seems logical to 
get an array of complex numbers but Complex needs to be declared 
with a type.


Thanks for any hint.

Re: Array of templated classes or structs

[Dandyvica via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 16:58:58 UTC, qsdfghjk wrote:

On Saturday, 24 October 2015 at 15:57:09 UTC, Dandyvica wrote:

Hi guys,

Apart from deriving from the same class and declaring an array 
of that

root class, is there a way to create an array of templates?

This seems not possible since template are compile-time 
generated, but just to be sure. For example, it seems logical 
to get an array of complex numbers but Complex needs to be 
declared with a type.


Thanks for any hint.


You can declare an array whose the element type matches to one 
of the template parameter:


---
struct Foo(T)
{
Foo!T[] foos;
// typeof(this)[] foos // equivalent
}
---

since it's an array (fixed size whatever is the element type: 
size_t len + size_t pointer) it doesn't matter if the template 
declaration is partial.


In that case, all elements have the same type right? I'd like 
different types,

but with the same template.

Fixing spurious "statement is not reachable" in template code

[tsbockman via Digitalmars-d]

While improving the DMD front-end's constant folding:
https://github.com/D-Programming-Language/dmd/pull/5229
I found out about DMD issue 14835:
https://issues.dlang.org/show_bug.cgi?id=14835

Briefly:
///
module main;

import std.stdio;

void reachIf(bool x)()
{
if(!x)
return;
writeln("reached"); // Warning: statement is not reachable
}

void main(string[] args) {
reachIf!true();  // prints "reached"
reachIf!false(); // triggers warning
}
///

This is, I think, a big problem.

Affected code is rare today, but that is only because DMD's 
constant folding and value-range-propagation is weak. The more 
improvements are made in this area, the more common erroneous 
"statement is not reachable" warnings will become.


Unfortunately, from what I can tell, this bug is just a natural 
consequence of DMD's current design; I think an ideal fix will 
not be simple.


Some possible solutions:

1. Defer "not reachable" warnings until compilation has been 
completed, and only issue the warning if *all* instantiations of 
the statement were unreachable.


2. For semantic analysis purposes, first instantiate each 
template using dummy parameters with the widest possible VRP 
ranges. Only statements found to be "not reachable" in this dummy 
run should actually generate warnings.


3. ??? I don't know the compiler internals very well, so I may be 
missing a more elegant solution.


From #1 and #2, #2 is the "correct" choice - if implemented 
properly, it would produce precisely the results I expect, as a 
user.


However, I think it would take a huge patch touching many 
different files and functions to implement. This seems excessive, 
assuming the only benefit is eliminating some spurious warnings.


#1 would still allow some false positives, but they should be 
quite rare, and also solvable by the user. Otherwise, this seems 
like a good approach:


* The size and complexity of the patch should be more reasonable.

* If all messages are deferred, it should be easy to condense the 
floods of duplicate messages generated by templates. Instead of 
getting the same message duplicated once per instantiation, you 
could just have one copy with a `x37` next to it or something.


* Likewise, if desired, messages could be sorted by file and line.

The main disadvantage that I see to approach #1 is that messages 
will not be printed until compilation is completed - which might 
be never, if the compiler hangs or something.


Thoughts?

Re: Array of templated classes or structs

[TheFlyingFiddle via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 15:57:09 UTC, Dandyvica wrote:

Hi guys,

Apart from deriving from the same class and declaring an array 
of that

root class, is there a way to create an array of templates?

This seems not possible since template are compile-time 
generated, but just to be sure. For example, it seems logical 
to get an array of complex numbers but Complex needs to be 
declared with a type.


Thanks for any hint.
Structs or classes that are templated will create new types each 
time they are instantiated.


struct S(T) { /*stuff*/ }
static assert(!is(S!int == S!double));

So you can create arrays of:
S!int[] a; or
S!double[] b;

But you can't really create arrays of S!(int or double)[].

However it can be sort of done by using a variant(taged union).

import std.variant;
alias SIntOrDouble = Algebraic!(S!int, S!double);

SIntOrDouble[] array;
array ~= S!int(...);
array ~= S!double(...);


Now the array holds two items an S!int for the first item and an 
S!double for the second.


You can use it like this.
foreach(ref elem; array)
{
   if(auto p = elem.peek!(S!int))
   {
  //Do stuff with an S!int item
   }
   else if(auto p = elem.peek!(S!double))
   {
  //Do stuff with an S!double.
   }
}

Or like this:
foreach(ref elem; array)
{
   elem.visit!(
   (S!int i) => /*something with ints*/,
   (S!double d) => /*something with doubles*/
   );
}

Take a look at std.variant if you are interested.

A drawback to the Algebraic is that you must know all the 
different template instantiations that you will be using. If you 
don't know this I suggest you use a variant instead.


The line:
SIntOrDouble[] array;
changes to
Variant[] array;

With this you can hold anything in the array. This is both an 
advantage and a drawback, the advantage is that you can just add 
more templpate instantiations to the program as is evolves. But 
you lose static typing information so the compiler will not be 
able to help you anymore. For example this would be valid:


Variant[] array;
array ~= S!int(...);
array ~= S!double(...);
array ~= S!long(...);
array ~= "I am a string!";

And this is probably not what you want.

Re: Type of receiver

[Marc Schütz via Digitalmars-d]

On Saturday, 24 October 2015 at 09:54:43 UTC, Jacob Carlborg 
wrote:
When the template this parameter feature was added to the 
language it was possible to use it for static methods:


class Foo
{
static void foo(this T)()
{
pragma(msg, T.stringof);
}
}

class Bar : Foo {}

Foo.foo(); // prints "Foo"
Bar.foo(); // prints "Bar"

For some reason this feature was removed, it might be that it 
was never indented to work for static methods.


Can we make it work again for static methods? It would be 
really handy for creating Objective-C bindings.


It was changed in this PR:
https://github.com/D-Programming-Language/dmd/pull/1687

It's hard to tell whether it was intentional though. But IMO your 
code should work, so I suggest you file a bug report.

Re: Synchronized classes have no public members

[Spacen Jasset via Digitalmars-d]

On Tuesday, 20 October 2015 at 18:15:05 UTC, Bruno Medeiros wrote:

On 16/10/2015 08:02, Jacob Carlborg wrote:

On 2015-10-16 08:49, Dicebot wrote:

As far as I understand topic is about deprecating direct 
field access of

synchronized classes, method calls in synhronized classes and
`synchronized () {}` blocks will remain untouched.


Is it even possible to do synchronized classes in Java? That 
is, but

synchronized on the class declaration as in D.



No, it's not possible. `synchronized` in Java can only apply to 
methods, or the synchronized statement.


And (for a change), rightly so that it's not possible. This 
synchronized class feature seems to me a clumsy mis-feature. At 
first glance at least.


This change seems like a good idea.

As far as having synchronized classes go. I think they can be 
useful. If, as some of the respondents have said a synchronized 
class is wrong, then perhaps their classes are too big and indeed 
require fine grained locks everywhere. Or, if it is performance 
you are after, then that is the way you might do it.


If, however, you would like better defense against multi-threaded 
related breakage against your non time-critical class, a class 
wide lock, surely, would be of benefit.

Re: Fastest JSON parser in the world is a D project

[Laeeth Isharc via Digitalmars-d-announce]

On Thursday, 22 October 2015 at 20:10:36 UTC, rsw0x wrote:
On Thursday, 22 October 2015 at 19:16:00 UTC, Laeeth Isharc 
wrote:
On Thursday, 22 October 2015 at 18:23:08 UTC, Andrei 
Alexandrescu wrote:

On 10/22/2015 09:08 AM, Walter Bright wrote:

[...]


This has been a homerun. Congratulations for this work and 
also for publicizing it! (Consider it might have remained 
just one forum discussion read by all of 80 persons...) -- 
Andrei


We really do need to stop hiding our light under a bushel.  
Thinking in marketing terms doesn't always come easy to 
technically minded people, and I understand why, but 
ultimately the community benefits a great deal from people 
becoming aware of the very real benefits D has to offer (alas 
people won't just get it, even if you think they should), and 
there are personal career benefits too from helping 
communicate how you have applied D to do useful work.  It's 
hard to find great programmers and showing what you can do 
will pay off over time.


D has no well defined area to be used in. Everyone knows D, 
when written in a very specific C-mimicking way, is performant. 
But nobody is using C# or Scala or Python for performance.


You reply to my post, but I don't entirely see how it relates.  D 
is very flexible, and that's its virtue.  Because splitting a 
codebase across multiple languages does have a cost, even if it's 
often worth paying the cost in order to use the right till for 
the job when those tools are by their nature specialised.  I 
don't think everyone knows D is performant, and I wouldn't say 
fast JSON is written in a C mimicking way, taken as a whole.


Choices are based on making trade-offs, and the relevant data are 
not static, but constantly shifting.  When an SSD in 2015 that 
isn't especially pricey gives 2.1 Gig a sec throughput and one 
has many terabytes of text data a month to get through, and 
that's today and datasets keep growing and what I write today may 
be in use for years then the right decision will be a very 
different one to that five years ago.   That's not just my 
perception, but those in other fields where the problems are 
similar - bioinformatics and advertising data being some of the 
many others.  AdRoll is known for their Python work, but their 
data scientists use D.


And my point, which you didn't really reply to, is that as a 
community we should do a bit more to share our experiences on how 
D can be useful in doing real work.  As Walter observes, that's 
also something that pays off personally too.

[Issue 14627] Implicit conversion from uint to dchar allows dchar > dchar.max

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--- Comment #2 from thomas.bock...@gmail.com ---
The issue of dchar.max versus uint.max has been discussed on the forums:
http://forum.dlang.org/thread/qjmikijfluaniwnxh...@forum.dlang.org

It was decided that D compilers must support dchar values which are outside the
range of valid Unicode code points; otherwise handling encoding errors and the
like gets very awkward. Besides, actually enforcing a range less than that
which is actually representable by the binary format of dchar would be very
difficult to do in a performant way.

In light of this, I think #1 (Make dchar.max == uint.max) is the correct
solution. Allowing dchar.max to be less than its true maximum has probably
caused subtle bugs in some generic code.

The value of the maximum code point (0x10) should be moved to a separate
constant.

--

Re: Array of templated classes or structs

[qsdfghjk via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 17:06:13 UTC, Dandyvica wrote:

On Saturday, 24 October 2015 at 16:58:58 UTC, qsdfghjk wrote:

On Saturday, 24 October 2015 at 15:57:09 UTC, Dandyvica wrote:

Hi guys,

Apart from deriving from the same class and declaring an 
array of that

root class, is there a way to create an array of templates?

This seems not possible since template are compile-time 
generated, but just to be sure. For example, it seems logical 
to get an array of complex numbers but Complex needs to be 
declared with a type.


Thanks for any hint.


You can declare an array whose the element type matches to one 
of the template parameter:


---
struct Foo(T)
{
Foo!T[] foos;
// typeof(this)[] foos // equivalent
}
---

since it's an array (fixed size whatever is the element type: 
size_t len + size_t pointer) it doesn't matter if the template 
declaration is partial.


In that case, all elements have the same type right? I'd like 
different types,

but with the same template.


Then no, it's not possible, although some ugly workaround may 
allow the thing (array of pointer and something used to cast the 
pointer at runtime, like an AliasSeq). But by definition if you 
have serveral type in an aray it's not array...it's an agregate.

Re: Kinds of containers

[TheFlyingFiddle via Digitalmars-d]

On Saturday, 24 October 2015 at 09:22:37 UTC, Jacob Carlborg 
wrote:
Can these be implemented by the user just declaring a regular 
container as immutable? The implement will recognize if it's 
declared as immutable and adapt.


How can a type know it's qualifier?

struct Container(T)
{
   // access qualifier somehow do stuff with it
}

alias SM  = Container!int;
alias SIM = immutable Container!int;

It was my understanding that S!int only gets instantiated one 
time here? Or does the compiler instantiate (immutable S!int) and 
(S!int)? Or were you thinking of something else?

`clear`ing a dynamic array

[Shriramana Sharma via Digitalmars-d-learn]

Hello. I had first expected that dynamic arrays (slices) would provide a 
`.clear()` method but they don't seem to. Obviously I can always effectively 
clear an array by assigning an empty array to it, but this has unwanted 
consequences that `[]` actually seems to allocate a new dynamic array and 
any other identifiers initially pointing to the same array will still show 
the old contents and thus it would no longer test true for `is` with this 
array. See the following code:

import std.stdio;
void main()
{
  int a[] = [1,2,3,4,5];
  int b[] = a;
  writeln(a);
  writeln(b);
  //a.clear();
  a = [];
  writeln(a);
  writeln(b);
}

which outputs:

[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[1, 2, 3, 4, 5]

How to make it so that after clearing `a`, `b` will also point to the same 
empty array? IOW the desired output is:

[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[]

... and any further items added to `a` should also reflect in `b`. 

-- 
Shriramana Sharma, Penguin #395953

Re: Type of receiver

[bitwise via Digitalmars-d]

On Saturday, 24 October 2015 at 09:54:43 UTC, Jacob Carlborg 
wrote:
When the template this parameter feature was added to the 
language it was possible to use it for static methods:


class Foo
{
static void foo(this T)()
{
pragma(msg, T.stringof);
}
}

class Bar : Foo {}

Foo.foo(); // prints "Foo"
Bar.foo(); // prints "Bar"

For some reason this feature was removed, it might be that it 
was never indented to work for static methods.


Can we make it work again for static methods? It would be 
really handy for creating Objective-C bindings.


I was looking at this a couple of days ago. It would be really 
useful if I could do this:


class TypeInfo {}
class TypeInfoImpl(T) : TypeInfo {}

class BaseObject {
static TypeInfo typeInfo(this This)() {
return TypeInfoImpl!This();
}

static TypeInfo info = typeInfo();
}
class Foo : BaseObject {
// also has 'info' with correct info for 'Foo'.
}

So, all subclasses of 'BaseObject' would get the appropriate type 
info. I would be using 'BaseObject' as a node in a scene graph. 
So everyone who defined new objects to go in the scene graph 
would have the appropriate type info added to their class without 
having to override some virtual function manually.


Bit

Re: Coedit 2 alpha 1 - now with dub

[qsdfghjk via Digitalmars-d-announce]

On Friday, 23 October 2015 at 06:55:37 UTC, Rory McGuire wrote:
I think IDE devs are supposed to use `dub describe` not read 
the package

file directly.
That whole package loading section of dub should probably be a 
library

though.

On Fri, Oct 23, 2015 at 8:47 AM, Eliatto via 
Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> 
wrote:



On Friday, 25 September 2015 at 05:08:05 UTC, BBasile wrote:

- compile, run, choose the configuration and the build type. 
but only the JSON format is handled.


BTW, why there are two formats for dub? Which one will be 
obsolete? It's a headache for IDE developers.


`dub describe` cannot be used currently for an advanced GUI. It 
has a latency issue due to dependencies checking. Coedit has a 
full DUB editor (http://imgur.com/a/WiXr7). Using this command 
would imply:


- change value in the GUI tree.
- save file.
- get and wait for the description, load and parse anyway to get 
the tree...

- update GUI.

and this for each single modification.

And I agree with you concerning the two formats. When SDL was 
announced I directly knewn that it would be a problem because 
this is a very "marginal" format. The official SDL homepage has 
been broken for monthes, showing how widely spreaded and trendy 
it is (giving the feeling that it was not even worth fixing the 
server). And there is almost no bindings for SDL at all.


Afaik, neither MonoD nor Visual-D support the SDL format. 
(although Visual-D could since it's written in D so the SDL 
library exists...).

Re: `clear`ing a dynamic array

[John Colvin via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 13:18:26 UTC, Shriramana Sharma 
wrote:
Hello. I had first expected that dynamic arrays (slices) would 
provide a `.clear()` method but they don't seem to. Obviously I 
can always effectively clear an array by assigning an empty 
array to it, but this has unwanted consequences that `[]` 
actually seems to allocate a new dynamic array and any other 
identifiers initially pointing to the same array will still 
show the old contents and thus it would no longer test true for 
`is` with this array. See the following code:


import std.stdio;
void main()
{
  int a[] = [1,2,3,4,5];
  int b[] = a;
  writeln(a);
  writeln(b);
  //a.clear();
  a = [];
  writeln(a);
  writeln(b);
}

which outputs:

[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[1, 2, 3, 4, 5]

How to make it so that after clearing `a`, `b` will also point 
to the same empty array? IOW the desired output is:


[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[]

... and any further items added to `a` should also reflect in 
`b`.


D's arrays are not pure reference types, they work like `struct 
Array(T) { size_t length; T* ptr; }` with some extra methods and 
operators. If you think of them like that it should be clear what 
is/isn't possible.


If you want to have two references to the same array, including 
the length, use T[]* or a ref argument to a function or wrap it 
in a class.

Re: How to install DMD 64bit on Windows?

[ric maicle via Digitalmars-d-learn]

On Thursday, 22 October, 2015 02:50 AM, Adam D. Ruppe wrote:

Use the .exe installer and it will offer to download and install visual
studio for you as part for its process.


Sorry to ask this but could anyone please explain why Visual Studio is
required by DMD 64-bit? (I have been away far too long than I should
have)

Thanks

Re: Is dlangui dead?

[karabuta via Digitalmars-d]

On Saturday, 24 October 2015 at 12:14:18 UTC, suliman wrote:

On Saturday, 24 October 2015 at 12:07:29 UTC, karabuta wrote:

On Friday, 23 October 2015 at 10:09:36 UTC, Chris wrote:

On Thursday, 22 October 2015 at 20:14:06 UTC, karabuta wrote:

On Tuesday, 20 October 2015 at 17:58:07 UTC, tcak wrote:

On Tuesday, 20 October 2015 at 17:01:19 UTC, karabuta wrote:
I hope I am wrong, but dlangui seems to be abandoned for 
some time after all the hard work that went into it. I 
really like it since it was easy to setup and get things 
working.



In fact, I consider it the best option.


So, are you planning to fork it, and continue its 
development as it was being developed by other developers?


If only I knew how. Even then, I would not fork it but 
rather help out. Since making bindings to qt is a lot of 
work and unlikely to happen any time soon, I planned to go 
with dlangui.


Have a look at:

http://wiki.dlang.org/Libraries_and_Frameworks#GUI_Libraries

GtkD is pretty stable I think. wxD should also be ok, though 
I haven't tried it yet. Have a look at iup. The original is 
supposed to be rock solid. Or try any other of the wrappers 
listed there.


At this stage, I'd recommend you to go with a wrapper. Native 
D GUIs come and go and you might get stuck. With wrappers you 
know what you get and if there's anything missing, you can 
interface to the original framework yourself.


GtkD has loads of the nice features that Gtk has, e.g. a 
source code editor (with line numbers and syntax 
highlighting). You can use Glade to build the interface (drag 
and drop): https://glade.gnome.org/


Thanks for the insights.


Try this
https://github.com/filcuc/DOtherSide


How cross platform is dqml by the way?

Re: Kinds of containers

[Kagamin via Digitalmars-d]

On Friday, 23 October 2015 at 17:44:55 UTC, deadalnix wrote:

void foo(T)(const Collection!const(T) c) {}
void main() {
  Collection!T c;
  foo(c); // Error, GTFO !
}


How about this?

void f(T)(const Collection!T c)
{
  const Collection!(Unqual!T) cc = c;
}

Re: No shortcircuit for static if or template constraints?

[stewart via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 23:26:09 UTC, stewart wrote:

Hi All,

Given this code:

---
import std.traits;
import std.range;
import std.stdio;

enum isSupportedRange(T) = (isInputRange!T && 
isIntegral!(ForeachType!T));


void func(T)(T vals)
{
static if(isSupportedRange!T) {
// Do something with a range
} else {
// Do something with a scalar
}
}

void main() {
int a1 = 0;
int[] a2 = [1,2,3];

func(a1);
func(a2);
}
---

I a compile error like so:

...std/traits.d(6136): Error: invalid foreach aggregate 0
hack.d(6): Error: template instance std.traits.ForeachType!int 
error instantiating

hack.d(10):instantiated from here: isSupportedRange!int
hack.d(22):instantiated from here: func!int

However, if I remove the Foreach part the "isInputRange!T" 
clearly fails.


I also tried overloading the function like so:

---
enum isSupportedRange(T) = (isInputRange!T && 
isIntegral!(ForeachType!T));


void func(T)(T vals) if(isSupportedRange!T) {
// Do something with a range
}
void func(T)(T vals) if(isNumeric!T) {
// Do something with a scalar
}
---

Again, if I remove the Foreach part and ignore element type of 
the range it works OK.


Am I doing something wrong?

Thanks,
stew



Oh and the workaround I'm using is this:

---
void func(T)(T vals) {
static if(isInputRange!T) {
static if(isIntegral!(ForeachType!T)) {
// Do something with range
}
} else {
// do something with scalar
}
}
---

which is a bit ugly.

Re: No shortcircuit for static if or template constraints?

[stewart via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 23:59:02 UTC, qsdfghjk wrote:

On Saturday, 24 October 2015 at 23:34:19 UTC, stewart wrote:

On Saturday, 24 October 2015 at 23:26:09 UTC, stewart wrote:

[...]



Oh and the workaround I'm using is this:

---
void func(T)(T vals) {
static if(isInputRange!T) {
static if(isIntegral!(ForeachType!T)) {
// Do something with range
}
} else {
// do something with scalar
}
}
---

which is a bit ugly.


Maybe this could work:

---
enum isSupportedRange(T) = isInputRange!T && is(ForeachType!T) 
&& (isIntegral!(ElementType!T));

---

ElementType() should return exactly what you excpeted with 
ForeachType().


Yep, that works, thanks!


I also found I can do it with __traits, but I think your way is 
cleaner.


enum bool isSupportedRange(T) = __traits(compiles, isInputRange!T 
&& isIntegral!(ForeachType!T));


cheers,
stew

Re: No shortcircuit for static if or template constraints?

[qsdfghjk via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 23:59:02 UTC, qsdfghjk wrote:

On Saturday, 24 October 2015 at 23:34:19 UTC, stewart wrote:

On Saturday, 24 October 2015 at 23:26:09 UTC, stewart wrote:

[...]



Oh and the workaround I'm using is this:

---
void func(T)(T vals) {
static if(isInputRange!T) {
static if(isIntegral!(ForeachType!T)) {
// Do something with range
}
} else {
// do something with scalar
}
}
---

which is a bit ugly.


Maybe this could work:

---
enum isSupportedRange(T) = isInputRange!T && is(ForeachType!T) 
&& (isIntegral!(ElementType!T));

---

ElementType() should return exactly what you excpeted with 
ForeachType().


Oh no! there's been a copy & paste error. I actually meant:

---
enum isSupportedRange(T) = isInputRange!T  && 
(isIntegral!(ElementType!T));

Re: Kinds of containers

[Andrei Alexandrescu via Digitalmars-d]

On 10/24/15 3:19 PM, Timon Gehr wrote:

Even if this was possible, it would not be a very good idea. Persistent
data structures have use cases that would be hindered by required
transitive immutability.


This part I don't quite get. Are there any languages that offer 
containers with immutable topology but mutable slots, and call them 
persistent data structures? -- Andrei

Compilation time profiling

[tired_eyes via Digitalmars-d-learn]

Hi, are there any tools for compilation time profiling? I'm 
trying to find what part of the code increases compilation time 
and don't want to stumble around.

[Issue 15244] New: Misleading compiler warning: "Error: use .min_normal property instead of .min"

[via Digitalmars-d-bugs]

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

  Issue ID: 15244
   Summary: Misleading compiler warning: "Error: use .min_normal
property instead of .min"
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: acehr...@yahoo.com

void main() {
double.min;
}

Error: use .min_normal property instead of .min

I like the warning but it is misleading. When a person (especially a beginner)
writes double.min, they mean "the minimum value" but the warning tells them to
use something else: double.min_normal.

I recommend that the message be changed to something like

Error: .min is deprecated for floating point types. Do you mean -double.max or
double.min_normal?

Ali

--

No shortcircuit for static if or template constraints?

[stewart via Digitalmars-d-learn]

Hi All,

Given this code:

---
import std.traits;
import std.range;
import std.stdio;

enum isSupportedRange(T) = (isInputRange!T && 
isIntegral!(ForeachType!T));


void func(T)(T vals)
{
static if(isSupportedRange!T) {
// Do something with a range
} else {
// Do something with a scalar
}
}

void main() {
int a1 = 0;
int[] a2 = [1,2,3];

func(a1);
func(a2);
}
---

I a compile error like so:

...std/traits.d(6136): Error: invalid foreach aggregate 0
hack.d(6): Error: template instance std.traits.ForeachType!int 
error instantiating

hack.d(10):instantiated from here: isSupportedRange!int
hack.d(22):instantiated from here: func!int

However, if I remove the Foreach part the "isInputRange!T" 
clearly fails.


I also tried overloading the function like so:

---
enum isSupportedRange(T) = (isInputRange!T && 
isIntegral!(ForeachType!T));


void func(T)(T vals) if(isSupportedRange!T) {
// Do something with a range
}
void func(T)(T vals) if(isNumeric!T) {
// Do something with a scalar
}
---

Again, if I remove the Foreach part and ignore element type of 
the range it works OK.


Am I doing something wrong?

Thanks,
stew

Re: Type of receiver

[bitwise via Digitalmars-d]

On Saturday, 24 October 2015 at 16:05:15 UTC, bitwise wrote:

[...]
class TypeInfo {}
class TypeInfoImpl(T) : TypeInfo {}

class BaseObject {
static TypeInfo typeInfo(this This)() {
return TypeInfoImpl!This();
}

static TypeInfo info = typeInfo();
}
class Foo : BaseObject {
// also has 'info' with correct info for 'Foo'.
}
[...]
Bit


Realizing now that this was a little bit of a brain fart...

My point is though, that it would be awesome if we could have 
functionality automatically generated by the compiler for all 
subclasses...but have it useable as a virtual method.


Maybe:

class Base {
/* virtual function that is automatically
 instantiated for all subclasses */
synthesized void foo(this This)() {
doSomething!This;
}
}
class Derived : Base {
// foo automatically overridden for this class.
}

Bit

Memory fragmentation

[Kagamin via Digitalmars-d]

An interesting article about memory fragmentation: 
http://nfrechette.github.io/2015/06/25/out_of_memory/

Re: Compilation time profiling

[Vladimir Panteleev via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 21:56:05 UTC, tired_eyes wrote:
Hi, are there any tools for compilation time profiling? I'm 
trying to find what part of the code increases compilation time 
and don't want to stumble around.


There's this:

https://github.com/CyberShadow/DBuildStat

Example output:

https://github.com/rejectedsoftware/vibe.d/issues/208#issuecomment-15875240

Re: Kinds of containers

[Timon Gehr via Digitalmars-d]

On 10/24/2015 09:33 PM, David Nadlinger wrote:

On Friday, 23 October 2015 at 17:44:55 UTC, deadalnix wrote:

Collection!T and Collection!const(T) are 2 completely different types.


Isn't this also required anyway because of covariance vs. contravariance
considerations?

  — David


(I'm assuming 'this' is referring to a solution to the problem.)

Yes, basically one often wants bit-by-bit conversions between structs 
whose fields corecursively convert to each other bit-by-bit. If we had 
opImplicitCastTo, this could probably be implemented (somewhat 
inefficiently) in the library, but a targeted language feature might be 
in order.

Re: Array of templated classes or structs

[TheFlyingFiddle via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 19:00:57 UTC, TheFlyingFiddle 
wrote:
One thing about variant is that if the struct you are trying to 
insert is larger then (void delegate()).sizeof it will allocate 
the wrapped type on the gc heap.


This is not a concern if you want to have class templates as they 
are on the heap anyways and have a fixed size.

Re: Array of templated classes or structs

[TheFlyingFiddle via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 18:40:02 UTC, TheFlyingFiddle 
wrote:
To complete TemplateStruct simply forward the remaing members 
of the
variant. Or use something like proxy!T in std.typecons. Or use 
an alias this v.
(I don't really recommend alias this it has all kinds of 
problems)


One thing about variant is that if the struct you are trying to 
insert is larger then (void delegate()).sizeof it will allocate 
the wrapped type on the gc heap. This might be detrimental to 
performance. So to help with this you could add an extra element 
on the TemplateStruct to sort of handle this.


struct TemplateStruct(alias template_, size_t size = (void 
delegate).sizeof)

{
VariantN!(size) v;
//Rest is the same.
}

Pick a good size for the template you want to make arrays of and 
it will lessen the stress on the gc heap.


For example:
struct vec4(T)
{
T[4] data;
//stuff
}

alias Vector4 = TemplateStruct!(template_, vec4!(double).sizeof);
Vector4[] array;

Additionaly you might want to look into the 
(http://forum.dlang.org/thread/jiucsrcvkfdzwinqp...@forum.dlang.org) if your interested in some cool stuff that can be done to call methods on such variant structs.

Re: Type of receiver

[Jacob Carlborg via Digitalmars-d]

On 2015-10-24 15:38, Marc Schütz wrote:


It was changed in this PR:
https://github.com/D-Programming-Language/dmd/pull/1687

It's hard to tell whether it was intentional though. But IMO your code
should work, so I suggest you file a bug report.


I did that, back in 2013 [1]. It was closed as invalid.

[1] https://issues.dlang.org/show_bug.cgi?id=10488

--
/Jacob Carlborg

Re: Is dlangui dead?

[Suliman via Digitalmars-d]

Try this
https://github.com/filcuc/DOtherSide


How cross platform is dqml by the way?


I think it should be work on Linux too. On Windows it's fine. 
Maybe even MacOSX will work. Also you may look at 
http://www.dsfml.com/

Re: LDC 0.16.0 has been released!

[Kai Nacke via Digitalmars-d-announce]

On Saturday, 24 October 2015 at 04:59:02 UTC, suliman wrote:

On Thursday, 22 October 2015 at 19:00:07 UTC, Kai Nacke wrote:

Hi everyone,

LDC 0.16.0, the LLVM-based D compiler, is available for 
download!
This release is based on the 2.067.1 frontend and standard 
library and supports LLVM 3.1-3.7 (OS X: no support for 3.3).


Don't miss to check if your preferred system is supported by 
this release. We also have a Win64 compiler available!


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

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

Regards,
Kai


If I not mistaken next version would be 1.0?


Next version will be 0.17 (based on 2.068 frontend still written 
in C++). But the next after next version will be 1.0 (based on 
2.069 which includes the frontend written in D).


Regards,
Kai

Re: Kinds of containers

[Timon Gehr via Digitalmars-d]

On 10/24/2015 09:22 PM, Andrei Alexandrescu wrote:

On 10/24/15 3:19 PM, Timon Gehr wrote:

Even if this was possible, it would not be a very good idea. Persistent
data structures have use cases that would be hindered by required
transitive immutability.


This part I don't quite get.


The slots are not mutable, but they are not /transitively/ immutable 
either. Note that this does not require any special effort, nor does it 
/prevent/ stored elements from being (transitively) immutable. Scala 
does it this way. (Haskell as well, basically.)



Are there any languages that offer
containers with immutable topology but mutable slots, and call them
persistent data structures? -- Andrei


Not that I know of, unless you count the hidden updates Haskell 
implementations may perform in order to provide lazy semantics (which 
'immutable' in D prevents, this alone is a sufficient reason not to 
force it on users).
However, that would be useful as well (as a potential performance 
optimization if the identity of the stored elements does not matter).



This paper of Sarnak and Tarjan discusses a version of what they call 
persistent rb-trees that only allows updates on the last version (which 
is often sufficient). (The point of the restriction is to lower space 
usage.) It changes color information on existing nodes and it keeps 
mutable lists in the nodes (i.e. making the nodes immutable would not work.)


http://www.link.cs.cmu.edu/15859-f07/papers/point-location.pdf

One might now say that those implementation details don't matter, and 
that the slots should still be transitively immutable. Well, one may 
want to use such data structures _within_ other persistent data structures.


(Just consider e.g. the case where, given a 3D point cloud of size n, 
and a number of axis-aligned boxes, you want a way to count the number 
of points in each box, given that the boxes arrive in an online fashion, 
while the points are known from the start. (Here, we want O(n log² n) 
preprocessing time, O(n log n) space and O(log² n) query time). One way 
to achieve that involves storing instances of an augmented version of 
their persistent rb-tree (they should support the range queries I have 
mentioned in my list of useful data structures) within a persistent 
augmented tree with predetermined O(log n)-depth topology (this 
container I had missed to mention).)


You can't do that if slots are transitively immutable.

Re: No shortcircuit for static if or template constraints?

[qsdfghjk via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 23:34:19 UTC, stewart wrote:

On Saturday, 24 October 2015 at 23:26:09 UTC, stewart wrote:

[...]



Oh and the workaround I'm using is this:

---
void func(T)(T vals) {
static if(isInputRange!T) {
static if(isIntegral!(ForeachType!T)) {
// Do something with range
}
} else {
// do something with scalar
}
}
---

which is a bit ugly.


Maybe this could work:

---
enum isSupportedRange(T) = isInputRange!T && is(ForeachType!T) && 
(isIntegral!(ElementType!T));

---

ElementType() should return exactly what you excpeted with 
ForeachType().

Re: Array of templated classes or structs

[TheFlyingFiddle via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 18:29:08 UTC, TheFlyingFiddle 
wrote:

Variant[] array;
array ~= S!int(...);
array ~= S!double(...);
array ~= S!long(...);
array ~= "I am a string!";

And this is probably not what you want.


You can do this if you want to ensure that items stored in the 
variant are of

a specific template struct/class.

import std.traits, std.variant;
struct TemplateStruct(alias template_)
{
   private Varint v;
   void opAssign(TemplateStruct!template_ other)
   {
   this.v = other.v;
   }

   void opAssing(T)(T t) if(isInstanceOf!(template_, T))
   {
   this.v = t;
   }

   T* peek(T) { return v.peek!T; }
   auto visit(Handlers...) { return v.visit!handler; }
   //More variant stuff here.
}


This should work: (untested)
TemplateStruct!(S)[] array;
array ~= S!int(...);
array ~= S!long(...);
array ~= S!double(...);
array ~= "I am a string!"; //This line should issue a compiler 
error.


To complete TemplateStruct simply forward the remaing members of 
the
variant. Or use something like proxy!T in std.typecons. Or use an 
alias this v.

(I don't really recommend alias this it has all kinds of problems)

Re: Kinds of containers

[Timon Gehr via Digitalmars-d]

On 10/24/2015 11:22 AM, Jacob Carlborg wrote:

On 2015-10-21 13:05, Andrei Alexandrescu wrote:


1. Functional containers.

These are immutable; once created, neither their topology nor their
elements may be observably changed. Manipulating a container entails
creating an entire new container, often based on an existing container
(e.g. append takes a container and an element and creates a whole new
container).

Internally, functional containers take advantage of common substructure
and immutability to share actual data. The classic resource for defining
and implementing functional containers is
http://www.amazon.com/Purely-Functional-Structures-Chris-Okasaki/dp/0521663504.



Can these be implemented by the user just declaring a regular container
as immutable? The implement will recognize if it's declared as immutable
and adapt.



Even if this was possible, it would not be a very good idea. Persistent 
data structures have use cases that would be hindered by required 
transitive immutability.

Re: Kinds of containers

[David Nadlinger via Digitalmars-d]

On Friday, 23 October 2015 at 17:44:55 UTC, deadalnix wrote:
Collection!T and Collection!const(T) are 2 completely different 
types.


Isn't this also required anyway because of covariance vs. 
contravariance considerations?


 — David

Re: Is dlangui dead?

[Chris via Digitalmars-d]

On Saturday, 24 October 2015 at 12:07:29 UTC, karabuta wrote:



Thanks for the insights.


Sorry I meant tkd, not wxD.

Re: Vision

[Jonathan M Davis via Digitalmars-d]

On Saturday, 24 October 2015 at 09:14:40 UTC, Jacob Carlborg 
wrote:

On 2015-10-24 01:23, Adam D. Ruppe wrote:

We just recently got it in for Windows, pretty well auto 
generated, so I

should hope we can get it for Mac too.


Oh, I didn't know it was the automatically generated. My 
concern are these posts: 
http://forum.dlang.org/post/lan02e$3104$1...@digitalmars.com


The concern expressed by Sean in that thread would not apply to 
the Windows bindings, because the headers that they were 
generated from are in the public domain. It might still apply 
with the Objective C headers (since they're probably not in the 
public domain), but I do think that the concern is a bit paranoid.


- Jonathan M Davis

on std.net.curl high level functions

[Mengu via Digitalmars-d]

hi all

what do you think about high level functions such as get, post, 
put, delete returning a Request object with status code, headers 
and content as its properties rather than just the content? this 
would make things easier for n00bs and newcomers to D as everyone 
would not have to create their own httprequest.d file in order to 
get the status and headers along with the content.

Re: `clear`ing a dynamic array

[Shriramana Sharma via Digitalmars-d-learn]

rsw0x wrote:

> use std.container.array

Thanks all for all the recommendations. When would one use 
std.array.appender with a built-in array vs std.container.array.Array? What 
are the pros and cons on either side?

-- 
Shriramana Sharma, Penguin #395953

Re: Option types and pattern matching.

[Rikki Cattermole via Digitalmars-d]

On 25/10/15 6:01 PM, Nerve wrote:

Hello D community! First time poster, I'm utterly fascinated with this
language's mix of features. It's powerful and expressive.

There are just two conveniences I'd like to see out of D. The first is
pattern matching, a functional construct which can unwrap tuples or
other containers, usually evaluates to a value (in most languages), and
which almost always idiomatically enforces the programmer to match over
every possible case of a given type.

While ML-inspired languages like F# and OCaml have some good pattern
matching syntax, it's not syntax which would fit in to D; I suggest
taking inspiration of Rusts's matching construct.

match x {
 Some(7) => "Lucky number 7!",
 Some(_) => "No lucky number.",
 None => "No value found"
}

 From that bit of code, we can see another feature at work: The Option
type. It wraps another type (i.e. Option int, Option Car) and represents
a wrapped presence of a value of that type (Some(n), Some(aCar)) or an
absence of that type (None).


Option = Varient


Combined with pattern matching, we end up with a safe, functional
construct which can replace a switch statement in most cases, returns a
value, is incredibly compact and readable, and can be used with Options
to ensure that we always account for the possibility of a value not
present, eliminating a whole class of errors when we use it judiciously.

My only concern is that switch statements, while horrendous
syntactically, are extremely performant and essentially compile to a
series of branches.

Are there any counter-arguments for the implementation of these two
features? Is D in a state where language additions have come to a stop?


So basically a little bit of magic for matching if having a value or not 
and switch statement.


Since I have no idea what the difference between Some(_), None and 
default. I'll assume it's already doable.

Re: My experience from learning Polish language

[Ali Çehreli via Digitalmars-d]

On 10/24/2015 04:15 AM, Cauterite wrote:

On Saturday, 24 October 2015 at 11:01:24 UTC, grumpyalittle wrote:

My name is Daisy and I was on Erasmus program in Poland. During


This looks like spam to me.


Of course spam but it's pretty amusing. :) It must have happened like this:

- Polish language school, which happens to be named PROLOG hires 
spammers for some effective spamming.


- Clueless spammers search for newsgroups that are related to "prolog 
language".


- Prolog happens to be a programming language. So is D, and we get the 
spam. :)


(Why did I write all this?)

Ali

Re: Option types and pattern matching.

[Nerve via Digitalmars-d]

On Sunday, 25 October 2015 at 05:05:47 UTC, Rikki Cattermole 
wrote:
Since I have no idea what the difference between Some(_), None 
and default. I'll assume it's already doable.


_ represents all existing values not matched. In this case, 
Some(_) represents any integer value that is not 7. None 
specifically matches the case where no value has been returned. 
We are, in most languages, also able to unwrap the value:


match x {
Some(7) => "Lucky number 7!",
Some(n) => "Not a lucky number: " ~ n,
None => "No value found"
}

Or something to that effect. The equivalent switch statement 
right now would be:


if (x.hasValue()) {
switch (*x.peek!(int)) {
case 7:writeln("Lucky number seven!"); break;
default:   writeln("Not a lucky number: ", 
*x.peek!(int)); break;

}
} else {
writeln("No value.");
}

This does not return a value (is a procedural structure); the 
switch cannot match null; in order to unwrap, we must call peek() 
again; and between the extra if-else and the break statements, 
this is not as clean.


As a note, pattern matching could almost be considered an 
extended form of the ?: operator, which matches over value cases 
rather than boolean truthiness.


Apologies if this is all below you, I'm not in Andrei's or 
Walter's league, just an interested party trying to make 
suggestions to better the language.

Does D's GC release memory back to the OS?

[Richard White via Digitalmars-d-learn]

Just wondering if D's GC release memory back to the OS?
The documentation for the GC.minimize 
(http://dlang.org/phobos/core_memory.html#.GC.minimize) seems to 
imply that it does,
but watching my OS's memory usage for various D apps doesn't 
support this.

Re: Memory fragmentation

[Rikki Cattermole via Digitalmars-d]

On 25/10/15 9:05 AM, Kagamin wrote:

An interesting article about memory fragmentation:
http://nfrechette.github.io/2015/06/25/out_of_memory/


The last couple of streams + a bit of time off it.
I've spent quite a bit of it working on a host name + port router and 
the optimization function pretty much unfragments the memory of the tree.


Ironically, I have yet to be able to prove that fragmentation decreases 
performance in any way.

Option types and pattern matching.

[Nerve via Digitalmars-d]

Hello D community! First time poster, I'm utterly fascinated with 
this language's mix of features. It's powerful and expressive.


There are just two conveniences I'd like to see out of D. The 
first is pattern matching, a functional construct which can 
unwrap tuples or other containers, usually evaluates to a value 
(in most languages), and which almost always idiomatically 
enforces the programmer to match over every possible case of a 
given type.


While ML-inspired languages like F# and OCaml have some good 
pattern matching syntax, it's not syntax which would fit in to D; 
I suggest taking inspiration of Rusts's matching construct.


match x {
Some(7) => "Lucky number 7!",
Some(_) => "No lucky number.",
None => "No value found"
}

From that bit of code, we can see another feature at work: The 
Option type. It wraps another type (i.e. Option int, Option Car) 
and represents a wrapped presence of a value of that type 
(Some(n), Some(aCar)) or an absence of that type (None).


Combined with pattern matching, we end up with a safe, functional 
construct which can replace a switch statement in most cases, 
returns a value, is incredibly compact and readable, and can be 
used with Options to ensure that we always account for the 
possibility of a value not present, eliminating a whole class of 
errors when we use it judiciously.


My only concern is that switch statements, while horrendous 
syntactically, are extremely performant and essentially compile 
to a series of branches.


Are there any counter-arguments for the implementation of these 
two features? Is D in a state where language additions have come 
to a stop?

Re: LDC 0.16.0 has been released!

[Joakim via Digitalmars-d-announce]

On Sunday, 25 October 2015 at 03:22:39 UTC, Joakim wrote:
On Saturday, 24 October 2015 at 15:40:41 UTC, Jack Stouffer 
wrote:
That's surprising given that many were worried that switching 
to ddmd would slow compilation speeds down by at least 30%. 
Also, this does not seem to be using any of ldc's optimization 
flags.


Well, all three of those are ddmd: the only difference is 
whether ddmd is compiled by dmd, gdc, or ldc.  The 30% 
measurement was based on comparing the previously completely 
C++ dmd with ddmd:


http://forum.dlang.org/post/55c9f77b.8050...@dawg.eu


Whoops, posted before I was done writing.

The Travis CI run combines the time spent compiling ddmd, time 
spent compiling the druntime/phobos tests, and then running the 
tests.  The original 30% comparison was only for time spent 
compiling a D codebase, like phobos or vibe.d.


It's possible ldc takes longer to compile ddmd, but then the 
resulting ddmd takes less time to compile phobos.  That would 
have to be separated out.  It's also possible the backend is not 
the issue and the D frontend itself is slower than the C++ 
frontend, in which case using ldc to compile ddmd won't make a 
difference.

Re: LDC 0.16.0 has been released!

[Joakim via Digitalmars-d-announce]

On Saturday, 24 October 2015 at 15:40:41 UTC, Jack Stouffer wrote:

On Saturday, 24 October 2015 at 03:11:30 UTC, Joakim wrote:
The associated travis CI run that finally went green with ldc 
0.16.0 beta 2 took about as long as the other D compilers, so 
performance of ldc-compiled ddmd seems comparable:


https://travis-ci.org/D-Programming-Language/dmd/builds/85017266


That's surprising given that many were worried that switching 
to ddmd would slow compilation speeds down by at least 30%. 
Also, this does not seem to be using any of ldc's optimization 
flags.


Well, all three of those are ddmd: the only difference is whether 
ddmd is compiled by dmd, gdc, or ldc.  The 30% measurement was 
based on comparing the previously completely C++ dmd with ddmd:


http://forum.dlang.org/post/55c9f77b.8050...@dawg.eu

Re: Kinds of containers

[deadalnix via Digitalmars-d]

On Saturday, 24 October 2015 at 19:33:03 UTC, David Nadlinger 
wrote:

On Friday, 23 October 2015 at 17:44:55 UTC, deadalnix wrote:
Collection!T and Collection!const(T) are 2 completely 
different types.


Isn't this also required anyway because of covariance vs. 
contravariance considerations?


 — David


It is close, but not exactly the same. Covariance/contravariance 
can be emutalted via alias this without too much trouble for a 
container (however, it is hard to ensure correctness, but I'd 
assume not too hard). On the other hand, the qualifier thing 
turtle from the collection to the element in the collection, 
which is not that easy to achieve.

Re: Option types and pattern matching.

[Rikki Cattermole via Digitalmars-d]

On 25/10/15 6:45 PM, Nerve wrote:

On Sunday, 25 October 2015 at 05:05:47 UTC, Rikki Cattermole wrote:

Since I have no idea what the difference between Some(_), None and
default. I'll assume it's already doable.


_ represents all existing values not matched. In this case, Some(_)
represents any integer value that is not 7. None specifically matches
the case where no value has been returned. We are, in most languages,
also able to unwrap the value:

match x {
 Some(7) => "Lucky number 7!",
 Some(n) => "Not a lucky number: " ~ n,
 None => "No value found"
}

Or something to that effect. The equivalent switch statement right now
would be:

if (x.hasValue()) {
 switch (*x.peek!(int)) {
 case 7:writeln("Lucky number seven!"); break;
 default:   writeln("Not a lucky number: ", *x.peek!(int)); break;
 }
} else {
 writeln("No value.");
}


I'm pretty sure e.g. opEquals/opCmp should work here.
Shouldn't need to switch upon a primitive type. Theoretically could do 
it on a e.g. struct. Which has the special comparison that you want.



This does not return a value (is a procedural structure); the switch
cannot match null; in order to unwrap, we must call peek() again; and
between the extra if-else and the break statements, this is not as clean.

As a note, pattern matching could almost be considered an extended form
of the ?: operator, which matches over value cases rather than boolean
truthiness.

Apologies if this is all below you, I'm not in Andrei's or Walter's
league, just an interested party trying to make suggestions to better
the language.


No no it's fine. Only this morning I was toying with the idea of 
variable length struct's on IRC. Turns out, wouldn't really work.

Re: Is dlangui dead?

[suliman via Digitalmars-d]

On Saturday, 24 October 2015 at 12:07:29 UTC, karabuta wrote:

On Friday, 23 October 2015 at 10:09:36 UTC, Chris wrote:

On Thursday, 22 October 2015 at 20:14:06 UTC, karabuta wrote:

On Tuesday, 20 October 2015 at 17:58:07 UTC, tcak wrote:

On Tuesday, 20 October 2015 at 17:01:19 UTC, karabuta wrote:
I hope I am wrong, but dlangui seems to be abandoned for 
some time after all the hard work that went into it. I 
really like it since it was easy to setup and get things 
working.



In fact, I consider it the best option.


So, are you planning to fork it, and continue its 
development as it was being developed by other developers?


If only I knew how. Even then, I would not fork it but rather 
help out. Since making bindings to qt is a lot of work and 
unlikely to happen any time soon, I planned to go with 
dlangui.


Have a look at:

http://wiki.dlang.org/Libraries_and_Frameworks#GUI_Libraries

GtkD is pretty stable I think. wxD should also be ok, though I 
haven't tried it yet. Have a look at iup. The original is 
supposed to be rock solid. Or try any other of the wrappers 
listed there.


At this stage, I'd recommend you to go with a wrapper. Native 
D GUIs come and go and you might get stuck. With wrappers you 
know what you get and if there's anything missing, you can 
interface to the original framework yourself.


GtkD has loads of the nice features that Gtk has, e.g. a 
source code editor (with line numbers and syntax 
highlighting). You can use Glade to build the interface (drag 
and drop): https://glade.gnome.org/


Thanks for the insights.


Try this
https://github.com/filcuc/DOtherSide

LDC iOS cross-compiler with arm64

[Dan Olson via Digitalmars-d-announce]

This is another set of binaries and universal libs for the experimental
LDC iOS cross-compiler.  It is now based on LDC 0.15.2 (2.066.1) and
LLVM 3.6.1.

https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.15.2-151023

What's new?
- arm64 for iOS 64-bit devices
- C ABI compatibility improvements
- supports Xcode 7
- includes libcurl

The release download ldc2-ios-0.15.2-151023-osx.tar.xz should have
everything needed to run on an OS X build host in the same fashion as an
LDC release.  But I may have missed something.

Binary is named iphoneos-ldc2 so you can have both it and a native ldc2
in your PATH.  Usage of iphoneos-ldc2 is the same as ldc2 with the
addition of clang style -arch option to select the iOS architecture to
compile code for.  Valid -arch options are armv6, armv7, armv7s, arm64,
X86_64, or i386 (armv6 is not included in the druntime/phobos universal
libs however).

Xcode or similar is needed to link and bundle an iOS app.

Xcode is not D aware and I am unaware of a working plugin.  In the
meantime, xc-iphoneos-dc in the bin dir can be used as a custom *.d
build script.  Or you can compile D source externally and add your
libraries/object files to an Xcode project.

If you want to build LDC and the libs yourself, instructions are at:

https://github.com/smolt/ldc-iphone-dev

It is not a quick build because druntime and phobos have to be compiled
for five architectures (armv7, armv7s, arm64, i386, and x86_64).

Feedback is really appreciated.
-- 
Dan

Re: dchar undefined behaviour

[Dmitry Olshansky via Digitalmars-d]

On 24-Oct-2015 02:45, Anon wrote:

On Friday, 23 October 2015 at 21:22:38 UTC, Vladimir Panteleev wrote:

That doesn't sound right. In fact, this puts into question why
dchar.max is at the value it is now. It might be the current maximum
at the current version of Unicode, but this seems like a completely
pointless restriction that breaks forward-compatibility with future
Unicode versions, meaning that D programs compiled today may be unable
to work with Unicode text in the future because of a pointless
artificial limitation.


Unless UTF-16 is deprecated and completely removed from all systems
everywhere, there is no way for Unicode Consortium to increase the limit
beyond U+10. That limit is not arbitrary, but based on the technical
limitations of what UTF-16 can actually represent. UTF-8 and UTF-32 both
have room for expansion, but have been defined to match UTF-16's
limitations.


Exactly. Unicode officially limited UTf-8 to 10 in Unicode 6.0 or 
so. Previously it was expected to (maybe) expand beyond but it was 
decided to stay with 10 pretty much indefinitely because of UTF-16.


Also; only ~114k of codepoints have assigned meaning, we are looking at 
900K+ unassigned values reserved today.


--
Dmitry Olshansky

Re: Vision

[Jacob Carlborg via Digitalmars-d]

On 2015-10-24 02:57, Laeeth Isharc wrote:


I read it quickly so may have missed, but I meant in the vision document ;)


Oh, no I understand :). I guess it's not part of the vision. You have to 
ask Andrei/Walter about that.


Personally, for me, it doesn't matter. I won't work more or less on this 
because it's part of or not part of of the vision document.


--
/Jacob Carlborg

Re: Kinds of containers

[Jacob Carlborg via Digitalmars-d]

On 2015-10-21 13:05, Andrei Alexandrescu wrote:


1. Functional containers.

These are immutable; once created, neither their topology nor their
elements may be observably changed. Manipulating a container entails
creating an entire new container, often based on an existing container
(e.g. append takes a container and an element and creates a whole new
container).

Internally, functional containers take advantage of common substructure
and immutability to share actual data. The classic resource for defining
and implementing functional containers is
http://www.amazon.com/Purely-Functional-Structures-Chris-Okasaki/dp/0521663504.


Can these be implemented by the user just declaring a regular container 
as immutable? The implement will recognize if it's declared as immutable 
and adapt.


--
/Jacob Carlborg

Re: inout, delegates, and visitor functions.

[Sebastien Alaiwan via Digitalmars-d-learn]

Hi ponce,
Thanks for your suggestion.
I think I may have found the beginning of a solution:

class E
{
  import std.traits;

  void apply(this F, U)(void delegate(U e) f)
if(is(Unqual!U == E))
  {
f(this);
  }

  int val;
}

int main()
{
  void setToZero(E e)
  {
e.val = 0;
  }

  void printValue(const E e)
  {
import std.stdio;
writefln("Value: %s", e.val);
  }

  E obj;

  obj.apply();
  obj.apply();

  const(E) objConst;
  //objConst.apply();
  objConst.apply();

  return 0;
}


Basically, I avoid the 'const'/'inout' attribute of the 'apply' 
function by using a 'this F' template argument.
Then, I need a second template argument 'U', otherwise, I can't 
call 'printValue' on a non-const E instance.

Re: inout, delegates, and visitor functions.

[ponce via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 11:28:17 UTC, Sebastien Alaiwan 
wrote:

Hi ponce,
Thanks for your suggestion.
I think I may have found the beginning of a solution:

class E
{
  import std.traits;

  void apply(this F, U)(void delegate(U e) f)
if(is(Unqual!U == E))
  {
f(this);
  }

  int val;
}

int main()
{
  void setToZero(E e)
  {
e.val = 0;
  }

  void printValue(const E e)
  {
import std.stdio;
writefln("Value: %s", e.val);
  }

  E obj;

  obj.apply();
  obj.apply();

  const(E) objConst;
  //objConst.apply();
  objConst.apply();

  return 0;
}




Clever. It works because of const inference on template functions.
Didn't know you could use 'this' as a type.

Re: Is dlangui dead?

[karabuta via Digitalmars-d]

On Friday, 23 October 2015 at 10:09:36 UTC, Chris wrote:

On Thursday, 22 October 2015 at 20:14:06 UTC, karabuta wrote:

On Tuesday, 20 October 2015 at 17:58:07 UTC, tcak wrote:

On Tuesday, 20 October 2015 at 17:01:19 UTC, karabuta wrote:
I hope I am wrong, but dlangui seems to be abandoned for 
some time after all the hard work that went into it. I 
really like it since it was easy to setup and get things 
working.



In fact, I consider it the best option.


So, are you planning to fork it, and continue its development 
as it was being developed by other developers?


If only I knew how. Even then, I would not fork it but rather 
help out. Since making bindings to qt is a lot of work and 
unlikely to happen any time soon, I planned to go with dlangui.


Have a look at:

http://wiki.dlang.org/Libraries_and_Frameworks#GUI_Libraries

GtkD is pretty stable I think. wxD should also be ok, though I 
haven't tried it yet. Have a look at iup. The original is 
supposed to be rock solid. Or try any other of the wrappers 
listed there.


At this stage, I'd recommend you to go with a wrapper. Native D 
GUIs come and go and you might get stuck. With wrappers you 
know what you get and if there's anything missing, you can 
interface to the original framework yourself.


GtkD has loads of the nice features that Gtk has, e.g. a source 
code editor (with line numbers and syntax highlighting). You 
can use Glade to build the interface (drag and drop): 
https://glade.gnome.org/


Thanks for the insights.

[Issue 14835] Statement is not reachable doesn't play along generic code

[via Digitalmars-d-bugs]

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

--- Comment #6 from thomas.bock...@gmail.com ---
Here's a minimal compilable (requires dmd argument -wi, rather than -w)
example, for anyone trying to fix this:

module main;

import std.stdio;

void reachIf(bool x)()
{
if(!x)
return;
writeln("reached"); // Warning: statement is not reachable
}

void main(string[] args) {
reachIf!true();  // prints "reached"
reachIf!false(); // triggers warning
}

--

Re: LDC iOS cross-compiler with arm64

[Jacob Carlborg via Digitalmars-d-announce]

On 2015-10-24 12:01, Suliman wrote:


Would it be hard to add Windows/Linux host available? Would it be hard
to develop iOS apps on Windows in comparison of using MacOSX?


It depends on what you mean. Microsoft already supports developing iOS 
apps on Windows, but the building is actually performed on OS X.


--
/Jacob Carlborg

Re: My experience from learning Polish language

[Cauterite via Digitalmars-d]

On Saturday, 24 October 2015 at 11:01:24 UTC, grumpyalittle wrote:

My name is Daisy and I was on Erasmus program in Poland. During


This looks like spam to me.

Re: Vision

[Jacob Carlborg via Digitalmars-d]

On 2015-10-23 14:44, Steven Schveighoffer wrote:


Also, what type does 'id' map to?


I don't think that "id" is particular interesting. Apple is moving away 
from it more and more. They added the "instancetype" feature for the 
declarations of "init" and "alloc". They added generics for containers.


For a generic type to store any kind of object I would recommend using 
"NSObject" which is (in practice) the root of all classes. NSProxy is 
the only class I've seen which doesn't inherit from NSObject. Although 
it still conforms to the NSObject protocol.


I would recommend against using "id" to store both objects and C types.

--
/Jacob Carlborg

Re: LDC iOS cross-compiler with arm64

[Suliman via Digitalmars-d-announce]

Only binaries for OS X build host are available.
Would it be hard to add Windows/Linux host available? Would it be 
hard to develop iOS apps on Windows in comparison of using MacOSX?

Re: Vision

[Jacob Carlborg via Digitalmars-d]

On 2015-10-24 01:23, Adam D. Ruppe wrote:


We just recently got it in for Windows, pretty well auto generated, so I
should hope we can get it for Mac too.


Oh, I didn't know it was the automatically generated. My concern are 
these posts: http://forum.dlang.org/post/lan02e$3104$1...@digitalmars.com


--
/Jacob Carlborg

Re: Kinds of containers

[Timon Gehr via Digitalmars-d]

On 10/24/2015 01:36 AM, bitwise wrote:

On Friday, 23 October 2015 at 23:21:31 UTC, bigsandwich wrote:

On Friday, 23 October 2015 at 17:44:55 UTC, deadalnix wrote:

On Friday, 23 October 2015 at 11:03:37 UTC, Andrei Alexandrescu wrote:

[...]


Sure. We have a problem when it come to collection in the fact that
type qualifier do not turtle down as one would expect.

[...]


Its not just type qualifiers. Containers of derived types have the
same problem.  This is also a problem in C++.


Thinking deeper about this, it _should_ be the case that deadalnix's
example doesn't compile.

struct Container(T) {
 static if(is(T == const))
  int changesLayout; // etc...
 int stuff;
}

 Bit



One could introduce a way to indicate that const-conversions should be 
performed for instantiations of a given templated aggregate with 
identical layouts.

Re: DCD 0.7.1

[Dicebot via Digitalmars-d-announce]

On Tuesday, 20 October 2015 at 22:14:24 UTC, Brian Schott wrote:

On Tuesday, 20 October 2015 at 08:28:19 UTC, Dicebot wrote:
Which LDC is it supposed to build with? Trying latest stable 
(0.15.1) I get:
src/server/autocomplete.d(23): Error: module logger is in file 
'std/experimental/logger.d' which cannot be read


0.16 beta. I'll add another mention of this to the release 
notes.


Now that 0.16.0 has hit stable, DCD package in Arch is updated 
too.

Re: LDC iOS cross-compiler with arm64

[extrawurst via Digitalmars-d-announce]

On Saturday, 24 October 2015 at 07:07:18 UTC, Dan Olson wrote:
This is another set of binaries and universal libs for the 
experimental LDC iOS cross-compiler.  It is now based on LDC 
0.15.2 (2.066.1) and LLVM 3.6.1.


[...]


Cool work!

Can this be merged with official LDC eventually ?

--Stephan

inout, delegates, and visitor functions.

[Sebastien Alaiwan via Digitalmars-d-learn]

Hi all,

I'm trying to get the following code to work.
(This code is a simplified version of some algebraic type).
Is it possible to only declare one version of the 'apply' 
function?

Or should I declare the const version and the non-const version?

I tried using "inout", but I got the following error:

test.d(28): Error: inout method test.E.apply is not callable 
using a mutable object



class E
{
  void apply(void delegate(inout(E) e) f) inout
  {
f(this);
  }

  int val;
}

void m()
{
  void setToZero(E e)
  {
e.val = 0;
  }

  void printValue(const E e)
  {
import std.stdio;
writefln("Value: %s", e.val);
  }

  E obj;

  obj.apply();
  obj.apply();
}

Thanks!

Type of receiver

[Jacob Carlborg via Digitalmars-d]

When the template this parameter feature was added to the language it 
was possible to use it for static methods:


class Foo
{
static void foo(this T)()
{
pragma(msg, T.stringof);
}
}

class Bar : Foo {}

Foo.foo(); // prints "Foo"
Bar.foo(); // prints "Bar"

For some reason this feature was removed, it might be that it was never 
indented to work for static methods.


Can we make it work again for static methods? It would be really handy 
for creating Objective-C bindings.


--
/Jacob Carlborg

[Issue 14835] Statement is not reachable doesn't play along generic code

[via Digitalmars-d-bugs]

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

Marc Schütz  changed:

   What|Removed |Added

 CC||schue...@gmx.net

--

My experience from learning Polish language

[grumpyalittle via Digitalmars-d]

My name is Daisy and I was on Erasmus program in Poland. During 
this period I decided to try to learn this language, what I 
thought couldn’t be easy. I went to school of Polish (called 
Prolog, more info here: www.polishcourses.com) and I started with 
no expectations. But now I’m really glad that I did it. I met a 
lof of wonderful people (kind teachers and students from all over 
the world), I learned this language very quickly and that was 
amazing experience.

Merging two named Tuples

[Edwin van Leeuwen via Digitalmars-d-learn]

I am trying to write a function to merge two named structs, but 
am completely stuck on how to do that and was wondering if anyone 
good provide any help. I know I can access the different names 
with tup.fieldNames, but basically can't work out how to use that 
to build the new return type. Below is an outline of what I am 
trying to do (with unittest). Any pointers would be greatly 
appreciated.



/++
Merge two Aes structs

If it has similar named types, then it uses the second one.

Returns a new struct, with combined types.
+/
import std.typecons : Tuple;
template merge(T, U)
{
auto merge( T base, U other )
{
// Go over other.fieldNames and collect them for new tuple
// Go over base.fieldNames, ignoring the ones that other 
has as well

// Build newTuple
return newTuple;
}
}

///
unittest
{
auto xs = ["a","b"];
auto ys = ["c","d"];
auto labels = ["e","f"];
auto aes = Tuple!(string[], "x", string[], "y", string[], 
"label")(

xs, ys, labels );

auto nlAes = merge( aes, Tuple!(double[], "x",
double[], "y" )(
[0,1], [3,4] ) );

assertEqual( nlAes.x[0], 0 );
assertEqual( nlAes.label.front, "e" );
}

[Issue 15243] rejects-valid on variadic

[via Digitalmars-d-bugs]

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

Sebastien Alaiwan  changed:

   What|Removed |Added

 CC||ac...@free.fr

--

[Issue 15243] New: rejects-valid on variadic

[via Digitalmars-d-bugs]

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

  Issue ID: 15243
   Summary: rejects-valid on variadic
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ac...@free.fr

This code won't compile:

class E(Types...)
{
  void apply(U)(U delegate(Types[0]) f0)
  {
  }
}

void test()
{
  E!int e;

  int f(int) { return 0; }

  e.apply();
}

ace@ANTEC:~/projects/bugs/dmd$ dmd -c rejectsvalid1.d 
rejectsvalid1.d(15): Error: template rejectsvalid1.E!int.E.apply cannot deduce
function from argument types !()(int delegate(int _param_0)), candidates are:
rejectsvalid1.d(4):rejectsvalid1.E!int.E.apply(U)(U delegate(Types[0])
f0)


However, one can make it compile by introducing an alias:

class E(Types...)
{
  alias Types[0] T0;
  void apply(U)(U delegate(T0) f0)
  {
  }
}

I'm using DMD64 D Compiler v2.068.2

--

Re: inout, delegates, and visitor functions.

[ponce via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 08:51:58 UTC, Sebastien Alaiwan 
wrote:

Hi all,

I'm trying to get the following code to work.
(This code is a simplified version of some algebraic type).
Is it possible to only declare one version of the 'apply' 
function?

Or should I declare the const version and the non-const version?

I tried using "inout", but I got the following error:

test.d(28): Error: inout method test.E.apply is not callable 
using a mutable object



class E
{
  void apply(void delegate(inout(E) e) f) inout
  {
f(this);
  }

  int val;
}

void m()
{
  void setToZero(E e)
  {
e.val = 0;
  }

  void printValue(const E e)
  {
import std.stdio;
writefln("Value: %s", e.val);
  }

  E obj;

  obj.apply();
  obj.apply();
}

Thanks!




Hi Sebastien,

That was an interesting question and I didn't succeed with 
'inout' either without duplicating apply.
I have a partial solution here: 
http://dpaste.dzfl.pl/b5ec7f16b912 which templatizes the delegate 
type, but is probably not what you want.


The qualifier is not carried on to the apply() function. When 
taking a const delegate it will still not be const.

Re: Converting Unicode Escape Sequences to UTF-8

[Nordlöw via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 21:52:05 UTC, anonymous wrote:

On 22.10.2015 21:13, Nordlöw wrote:

Hmm, why isn't this already in Phobos?


Working first version at

https://github.com/nordlow/justd/blob/master/conv_ex.d#L207

Next I'll make it a range.