Re: 1st Ever Artificial Consciousness to be Written in D Language

[Chris via Digitalmars-d-announce]

On Friday, 4 September 2015 at 09:15:16 UTC, Ola Fosheim Grøstad 
wrote:
On Thursday, 3 September 2015 at 15:20:27 UTC, Nick Sabalausky 
wrote:
based on one hell of a gigantic assumption: That consciousness 
is a natural consequence of a sufficiently large neural net. 
It's a fine and interesting idea, but PURELY speculative, with 
zero evidence and not even any way of testing for evidence 
since, like you say, we can't even figure out the first thing 
about consciousness as it relates to ourselves and each other, 
let alone to machines.


Given a large enough table one could encode perceived human 
behaviour with a lookup-table... So all we need is a computer 
program that itself claims to possess consciousness. Would that 
be a scam? Maybe Asame Obiomah is a computer program claiming 
to be a man writing a computer program. Would that make it 
intelligent? Hm.


Maybe he'll come up with something that is more intelligent than 
your average tabloid reader :)))

Re: Casting away immutability

[jqb via Digitalmars-d-learn]

On Thursday, 3 September 2015 at 13:28:54 UTC, Sergei Degtiarev 
wrote:

[...]
Agree, however, memory obtained with mmap(..., PROT_READ, ..); 
is essentially read-only and any attempt to write to it will 
cause immediate crash with segmentation violation. It would be 
very desirable in this case to return something that could be 
cast to immutable(type)[] but not type[].

This is what I tried to find out. Thank you for the help.


It can still change by writing (in the same or another process) 
to the file via another file descriptor. Of course the results 
are non-deterministic in that case, so it doesn't much matter 
whether the compiler assumes the data to be immutable or not.

Re: 1st Ever Artificial Consciousness to be Written in D Language

[via Digitalmars-d-announce]

On Friday, 4 September 2015 at 10:11:18 UTC, Chris wrote:
Maybe he'll come up with something that is more intelligent 
than your average tabloid reader :)))


You should file a business-patent! That would be goldmine.

Re: Error reporting is terrible

[Jacob Carlborg via Digitalmars-d]

On 2015-09-04 12:37, Iain Buclaw via Digitalmars-d wrote:


On 4 September 2015 at 12:19, Russel Winder via Digitalmars-d
Wrong. Install Emacs.


Wrong. Install Butterflies.  =-P


There's already a command for that in Emacs ;)

--
/Jacob Carlborg

Re: Containers

[BBasile via Digitalmars-d]

On Thursday, 3 September 2015 at 19:45:48 UTC, bitwise wrote:

Any interest in having these in Phobos?

https://github.com/bitwise-github/d-containers

Phobos doesn't currently have a Queue(T), and Array(T) leaves 
much to be desired. The containers I've built are very full 
featured, fast, and are unittested fairly thoroughly. I intend 
to add range checking to both containers as well. Inspiration 
was taken from C++'s vector and queue, C#'s generic List and 
Queue, and D's Array.


I'm not sure how the container's I've built would be integrated 
though. They do go against the current container spec, but for 
good reason.


The container spec says containers should be reference types, 
but I guess this clashed with the idea of Phobos being @nogc so 
someone tried to make Array(T) ref counted. The result is 
std.container.Array being a struct with an instance of 
RefCounted inside it, which is bad for performance, but also 
inflexible. Innocent looking code like the following will do 2 
separate allocations: One for the RefCounted payload, and one 
for the Array's data. On top of being a performance hit, it 
doesn't allow the user to choose how they want to manage memory.


Array!int a = Array!int(1, 2, 3);//  2 allocations, or 
else!  >:D


The containers I've built are simple value types with a 
postblit. Using this as a base, one can simply use the 
container as-is if they like(which I do), but it's also trivial 
to make either a ref-counted version, or GC version.


See here for example:
https://github.com/bitwise-github/d-containers/blob/master/main.d

Bit


I think that std.allocators is a prerequisite to implement the 
some new std containers.


Examples:
- library array: gc_allocator for a "single shot" program is fine.
- library array: aligned_allocator if the array content has to be 
used with several SSE instructions.
- linked list: could use malloctor to automatically manage its 
payloads life-time, but the final choice will be a parameter of 
the template instance. Inside the template, some 'static if' 
branches to adapt the code to the allocator used to make new 
payloads.
Also a the free list to get available payloads instead of 
allocationg...etc.


New containers without std.mallocators would be an error. In this 
sense, EMSI allocators are a bit more compliant (they already use 
them, not exactly as required but   templates have an optional 
param to indicate if the structures are GC-free or not).

Re: Beta D 2.068.1-b2

[BBasile via Digitalmars-d-announce]

On Friday, 4 September 2015 at 11:44:44 UTC, BBasile wrote:
On Wednesday, 2 September 2015 at 18:20:49 UTC, Jacob Carlborg 
wrote:

[...]


apart from a compiler warning 
(https://msdn.microsoft.com/en-us/library/ms173153.aspx=


correct link:

https://msdn.microsoft.com/en-us/library/ms173153.aspx

Re: Bug in logger

[Steven Schveighoffer via Digitalmars-d]

On 9/4/15 4:30 AM, Robert burner Schadek wrote:

the sharedLog Logger (aka default logger) will only work after its
static this has run.


D shouldn't have a problem with this. It uses import dependencies to 
make sure the static ctors are run in dependency order.


-Steve

Re: Containers

[Russel Winder via Digitalmars-d]

On Thu, 2015-09-03 at 21:11 +, bitwise via Digitalmars-d wrote:
> On Thursday, 3 September 2015 at 19:45:48 UTC, bitwise wrote:
> 
> > I'm not sure how the container's I've built would be integrated
> 
> I suppose what I'm suggesting would be to integrate my new 
> containers and modify the spec to explain the new value type 
> containers, and start deprecating the old containers as better 
> versions become available...starting with Array(T)...
> 
> Or I could stop trying to make tangible contributions to D and 
> just go bikeshed about =+

Isn't the best route here to make a trivially accessible library (via
the Dub repository?) that people can choose to use instead of the bits
of Phobos that these data structures replace? This will then allow the
momentum of usage to apply pressure for the Phobos ones to be
deprecated and your new ones to be absorbed into Phobos…

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: 1st Ever Artificial Consciousness to be Written in D Language

[Chris via Digitalmars-d-announce]

On Friday, 4 September 2015 at 10:43:32 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 4 September 2015 at 10:11:18 UTC, Chris wrote:
Maybe he'll come up with something that is more intelligent 
than your average tabloid reader :)))


You should file a business-patent! That would be goldmine.


Not really. A tabloid reader can be modeled like this:

immutable TabloidReader tr =
[
  hate:fear,
  fear:hate
];

immutable Opinion ifYouAskMe(gibberish statement) @safe
{
  in
  {
assert(statement == bullsh*t);
  }
  out(result)
  {
assert(result == AbsoluteBullsh*t);
  }
  body
  {
return "I'm not racist, but " ~ statement;
  }
}

So you just need something that is a bit more sophisticated ;)

Re: reading file byLine

[deed via Digitalmars-d-learn]

On Friday, 4 September 2015 at 07:27:54 UTC, Namal wrote:

On Friday, 4 September 2015 at 01:55:13 UTC, deed wrote:

On Friday, 4 September 2015 at 01:31:28 UTC, Namal wrote:
How can I get just the maximum element? Do I need to give a 
range for it?


Use max? 
http://dlang.org/phobos/std_algorithm_comparison.html#max


Sorry, I don't understand the syntax yet. How do I tell max to 
search all elements?

You can search all elements by using reduce
http://dlang.org/phobos/std_algorithm_iteration.html#reduce


I mean, why does sort(myarray) is legit and max(myarray) isn't.

I don't know why, other than that is the current design in Phobos.


import std.algorithm, std.range, std.array, std.string, std.stdio,
std.conv;

int[] arr1 = [1, 2, 30];
//arr1.max.writeln; // Doesn't work, as you say
arr1.reduce!max.writeln;// This does. Prints 30.

int[] arr2 = [4, 5, 6];
int[][] arr = [arr1, arr2];
arr.reduce!max.writeln; // Returns either arr1 or arr2. 
Element by
// element comparison until one is 
greatest.

// Prints arr2, since 1 < 4.
arr.joiner.reduce!max.writeln; // Flattens arr1 and arr2 to one 
arr and

// finds max. Prints 30.

//For your example:
auto f = File("filename", "r");
auto numbers = f// 1 2 3\n4 5 6
.byLine // ["1 2 3", "4 5 6"]
.map!(a => a.split) // [["1", "2", "3"], ["4", "5", "6"]]
.map!(a => a.to!(int[]))// [[1, 2, 3], [4, 5, 6]]
.array; // Allocates and puts the elements 
into an

// int[][] for reuse of state.

numbers // [[1, 2, 3], [4, 5, 6]]
.map!(reduce!max)   // [3, 6]
.writeln;   // prints [3, 6]

numbers // [[1, 2, 3], [4, 5, 6]]
.joiner // [1, 2, 3, 4, 5, 6]
.reduce!max // 6
.writeln;   // prints 6

Re: Beta D 2.068.1-b2

[Steven Schveighoffer via Digitalmars-d-announce]

On 9/4/15 8:04 AM, Martin Nowak wrote:

On Tuesday, 1 September 2015 at 06:33:30 UTC, Jacob Carlborg wrote:

I suspect this is intended?


The problem is that you're hiding a method that is still reachable
through the vtable.
Rather than throwing a runtime error this was changed to a compiler error.

https://github.com/D-Programming-Language/dmd/pull/4606

You should not turn off deprecations btw ;).

The simple solution in you case is to override the inherited `string
toString()` with an implementation that forwards to your `toString()`.

class UniText
{
 override string toString() { return toString(null).idup; }
 abstract const char[] toString (char[]  dst = null);
 abstract const wchar[] toString16 (wchar[] dst = null);
 abstract const dchar[] toString32 (dchar[] dst = null);
}

Also see at
https://github.com/D-Programming-Language/druntime/blob/4e799b75ebcb6d00ccefbcfd763a1f5d158357a1/src/object.d#L1598
for an example of an alternative overridable toString method.
Maybe you should use the delegate based toString as well, it's already
supported by a some phobos formatting.


Why did this compile/pass tests then? I wasn't aware of this restriction.

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

-Steve

Re: Casting away immutability

[via Digitalmars-d-learn]

On Friday, 4 September 2015 at 08:37:26 UTC, Kagamin wrote:
On Thursday, 3 September 2015 at 13:28:54 UTC, Sergei Degtiarev 
wrote:
Agree, however, memory obtained with mmap(..., PROT_READ, ..); 
is essentially read-only and any attempt to write to it will 
cause immediate crash with segmentation violation. It would be 
very desirable in this case to return something that could be 
cast to immutable(type)[] but not type[].


If you can't write to it doesn't mean it won't change. Use 
const for memory that you can't write to.


Note that you can however achieve immutability by using a 
_private_ read-only mapping.

Re: 1st Ever Artificial Consciousness to be Written in D Language

[via Digitalmars-d-announce]

On Thursday, 3 September 2015 at 15:20:27 UTC, Nick Sabalausky 
wrote:
based on one hell of a gigantic assumption: That consciousness 
is a natural consequence of a sufficiently large neural net. 
It's a fine and interesting idea, but PURELY speculative, with 
zero evidence and not even any way of testing for evidence 
since, like you say, we can't even figure out the first thing 
about consciousness as it relates to ourselves and each other, 
let alone to machines.


Given a large enough table one could encode perceived human 
behaviour with a lookup-table... So all we need is a computer 
program that itself claims to possess consciousness. Would that 
be a scam? Maybe Asame Obiomah is a computer program claiming to 
be a man writing a computer program. Would that make it 
intelligent? Hm.

Re: reading file byLine

[Edwin van Leeuwen via Digitalmars-d-learn]

On Friday, 4 September 2015 at 12:06:08 UTC, Edwin van Leeuwen 
wrote:

On Friday, 4 September 2015 at 11:50:23 UTC, deed wrote:


import std.algorithm, std.range, std.array, std.string, 
std.stdio,

std.conv;

int[] arr1 = [1, 2, 30];
//arr1.max.writeln; // Doesn't work, as you say
arr1.reduce!max.writeln;// This does. Prints 30.


Again using reduce is the functional way to do it. The above 
basically boils down to:


int[] arr1 = [1, 2, 30];
int maxElement = arr1[1];
foreach( element; arr1[2..$] ) //2..$ is short hand for second 
till last ($) element

{
  maxElement = max( maxElement, element );
}
writeln( maxElement );


Sorry been using too much R, so my indexes are off by 1:

int[] arr1 = [1, 2, 30];
int maxElement = arr1[0];
foreach( element; arr1[1..$] ) //1..$ is short hand for second 
till last ($) element

{
  maxElement = max( maxElement, element );
}
writeln( maxElement );

Re: reading file byLine

[Edwin van Leeuwen via Digitalmars-d-learn]

On Friday, 4 September 2015 at 11:50:23 UTC, deed wrote:


import std.algorithm, std.range, std.array, std.string, 
std.stdio,

std.conv;

int[] arr1 = [1, 2, 30];
//arr1.max.writeln; // Doesn't work, as you say
arr1.reduce!max.writeln;// This does. Prints 30.


Again using reduce is the functional way to do it. The above 
basically boils down to:


int[] arr1 = [1, 2, 30];
int maxElement = arr1[1];
foreach( element; arr1[2..$] ) //2..$ is short hand for second 
till last ($) element

{
  maxElement = max( maxElement, element );
}
writeln( maxElement );

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

On 2/09/2015 11:23 PM, Rory McGuire via Digitalmars-d-announce wrote:

Surely if the dog food is so bad no one should be eating?


It's not that phobos is bad, it's that we're following the same 
development pattern we had with C++.  We're using a conservative subset 
of D features and libraries, and slowly expanding what's acceptable. 
For example, DMD now uses foreach and delegates in a few places, and I 
expect we'll see a lot of use of D strings in the near future.

Re: Status of Win32 C++ interop

[Benjamin Thaut via Digitalmars-d-learn]

On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner wrote:

Hi,

what is the current status of:

- Win x86/32bit/coff32 interop with C++?

- improvements for general C++ interop that were suppose to 
come with 2.068


If you use either the -m64 or -mscoff32 interop should be pretty 
good. I'm currently using it heavily and its working quite nicely.

Re: Status of Win32 C++ interop

[Benjamin Thaut via Digitalmars-d-learn]

On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote:


What about 32bit phobos? Last time I checked (2.067) only x64 
was distributed.


You have to compile it yourself. Use the win64 makefile and 
replace the arch=64 with

arch=32mscoff.

For more details see here:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html

Re: Error reporting is terrible

[Iain Buclaw via Digitalmars-d]

On 4 September 2015 at 12:19, Russel Winder via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Fri, 2015-09-04 at 03:26 +, David DeWitt via Digitalmars-d
> wrote:
> > […]
> >
> > Wipe Windows
> > Install Arch
>
> Or Debian Sid or Fedora.
>
>
Or Slackware


> > Install vim
>
> Wrong. Install Emacs.
>
>
Wrong. Install Butterflies.  =-P

Re: Beta D 2.068.1-b2

[Steven Schveighoffer via Digitalmars-d-announce]

On 9/4/15 8:20 AM, Steven Schveighoffer wrote:

On 9/1/15 3:13 PM, Jacob Carlborg wrote:

On 2015-09-01 15:40, Steven Schveighoffer wrote:


I'm not 100% sure, but that does seem like a bug.


I see now that there's a deprecation message when compiling with
2.067.0. So it looks like it's intended.



Really? I don't see any deprecation message for your exact code posted
when compiled on 2.067.


I take it back, the message occurs if you make the function concrete.

-Steve

Re: Status of Win32 C++ interop

[Szymon Gatner via Digitalmars-d-learn]

On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner 
wrote:


What about 32bit phobos? Last time I checked (2.067) only x64 
was distributed.


You have to compile it yourself. Use the win64 makefile and 
replace the arch=64 with

arch=32mscoff.

For more details see here:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html


Ah so that didn't change. Did you try it? Do you run hybrid C++/D 
apps on Win (whether 32 or 64)?. Asking because last time I tried 
it (Win x64 tho) writeln() call from D side crashed app because 
stdio wasn't properly initialized even tho rt_init() was 
successful.

Re: Interesting user mistake

[Steven Schveighoffer via Digitalmars-d]

On 9/3/15 5:59 PM, Brian Schott wrote:

On Thursday, 3 September 2015 at 17:17:26 UTC, Steven Schveighoffer wrote:

What about all other operations that may be typos from op= where op is
also a unary operator? e.g. =-


We'd have to special-case '*':

a=*b;



You could say the same thing for =-:

a=-b;

seems reasonable for someone who doesn't like whitespace. I think 
Andrei's rule was the token sequence must have whitespace after the 
operator in order to be rejected. So the above would be fine.


-Steve

Re: Error reporting is terrible

[Russel Winder via Digitalmars-d]

On Fri, 2015-09-04 at 03:26 +, David DeWitt via Digitalmars-d
wrote:
> […]
> 
> Wipe Windows
> Install Arch

Or Debian Sid or Fedora.

> Install vim

Wrong. Install Emacs.

> Install DMD.

And/or LDC, GDC

> Problem solved :)

Weee…

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Status of Win32 C++ interop

[Szymon Gatner via Digitalmars-d-learn]

Hi,

what is the current status of:

- Win x86/32bit/coff32 interop with C++?

- improvements for general C++ interop that were suppose to come 
with 2.068

Re: Status of Win32 C++ interop

[Szymon Gatner via Digitalmars-d-learn]

On Friday, 4 September 2015 at 08:58:41 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner 
wrote:

Hi,

what is the current status of:

- Win x86/32bit/coff32 interop with C++?

- improvements for general C++ interop that were suppose to 
come with 2.068


If you use either the -m64 or -mscoff32 interop should be 
pretty good. I'm currently using it heavily and its working 
quite nicely.


What about 32bit phobos? Last time I checked (2.067) only x64 was 
distributed.

Re: Beta D 2.068.1-b2

[Steven Schveighoffer via Digitalmars-d-announce]

On 9/1/15 3:13 PM, Jacob Carlborg wrote:

On 2015-09-01 15:40, Steven Schveighoffer wrote:


I'm not 100% sure, but that does seem like a bug.


I see now that there's a deprecation message when compiling with
2.067.0. So it looks like it's intended.



Really? I don't see any deprecation message for your exact code posted 
when compiled on 2.067.


-Steve

Re: Current state of GUI's

[Chris via Digitalmars-d]

On Thursday, 3 September 2015 at 15:15:47 UTC, motaito wrote:


Thanks for the details! I was afraid, of something like this. 
To me D doesn't seam very competitive without a complete 
toolset :( Given that D has been around for a while now I am 
somewhat surprised it's not further along. I know it's a lot of 
work and not easy to do but clearly there has been a need for 
this for many years now. The resources I found were several 
years old (not including that they must have been working on it 
for a while before abandoning the project). It will be hard to 
compete with something like QT.


I was hoping for a cross platform solution that would deliver 
good performance without the complexity of c/c++. But if there 
is no built in solution QT seams a better option. I wanted to 
avoid QT because of the added complexity and the QT-windows 
tend to lag on a windows platform. This may go away with 
updates and bugfixes though.


Anyway, I hope you will be successful with alphaPhobos. I think 
D needs it, so don't abandon it! I will keep an eye out and 
check again in about a year or so. But for now I have to 
rethink whether to use D or not.


Out of curiosity, why do you think that I wouldn't want a 
Phobos solution? Wouldn't an integrated solution be better? I 
would not have to maintain a build of an external third party 
project, that may or may not be abandoned in the future, not 
knowing whether there will be updates, bugfixes or missing 
features to be added. It seams like quite a bit extra 
management for my project if I have to keep a third party 
project up to date and may need to adjust my code due to an 
update in an external project.


Don't give up yet. I've learned that a D GUI is not so important. 
There is a plethora of platforms and devices (mobile phones, 
tablets, PCs etc etc), so it's better not to get married to one 
particular UI. Keep your program GUI-agnostic and then you can 
connect it to any GUI you want. And D is easy to connect to: 
C(++), Lua (LuaD) and Python (PyD).


With D you can concentrate on the program, the GUI could be 
anything. E.g. look at how the DCD/Dscanner plug-in works with 
Textadept and other editors.


https://github.com/Hackerpilot/DCD/wiki/IDEs-and-Editors-with-DCD-support

[Issue 15006] Compiling trivial program produces 400,000+ byte object file

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #2 from Vladimir Panteleev  ---
Can't reproduce with 2.068 with either -m32 or -m64

--

[Issue 15005] Coverage files start with a dash character when using full pathname for source files with -cov

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
Workaround: use ./-path-to-my-file.lst

--

Re: Beta D 2.068.1-b2

[BBasile via Digitalmars-d-announce]

On Wednesday, 2 September 2015 at 18:20:49 UTC, Jacob Carlborg 
wrote:

On 2015-09-02 17:51, Meta wrote:


Isn't that what `override` is for?


No. Think of it like you want to have a new method with the 
same name as a method in the base class. It's for hiding a 
method in the base class, not overriding it. See the C# 
documentation [1].


[1] https://msdn.microsoft.com/en-us/library/435f1dw2.aspx


What's so different with C# 'new' that not to call 'super' in a D 
overriden method ? (even if C# has itself 'base' instead of 
'super')


C#
---
public class BaseC
{
public int x;
public void Invoke() { }
}
public class DerivedC : BaseC
{
new public void Invoke() { }
}
---

D
---
class BaseC
{
int x;
void Invoke() { }
}
class DerivedC : BaseC
{
override void Invoke() { /*super.Invoke() not called*/ }
}
---

apart from a compiler warning 
(https://msdn.microsoft.com/en-us/library/ms173153.aspx=

[Issue 15012] New: Druntime Makefile whitelists compilers

[via Digitalmars-d-bugs]

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

  Issue ID: 15012
   Summary: Druntime Makefile whitelists compilers
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: c...@dawg.eu
  Reporter: thecybersha...@gmail.com

https://github.com/D-Programming-Language/druntime/pull/1317 added a whitelist
of compiler binaries for which to add certain CFLAGS. This precludes e.g. using
wrapper scripts to work around issue 12572.

This issue is blocking some of my work on D (I can't bisect certain bugs or
build D on certain machines).

Introduced in https://github.com/D-Programming-Language/druntime/pull/1317

I've notified the PR author in a comment on the PR five days ago, but no reply:

https://github.com/D-Programming-Language/druntime/pull/1317#discussion_r38268116

--

Re: 1st Ever Artificial Consciousness to be Written in D Language

[Guy Gervais via Digitalmars-d-announce]

On Wednesday, 2 September 2015 at 14:41:20 UTC, GrandAxe wrote:
This is to inform the D Language community that the first 
viable general artificial algorithm is being written in D. It 
is called Organic Big data intelligence (OBI); the website is 
at www.okeuvo.com.


Some of its capabilities are:

1. Ability to learn
2. Ability to analyse
3. Problem solving
4. Moral judgement
5. Ability to feel emotions
6. Free will
7. Consciousness
8. Self awareness

D Language was chosen for its versatility. It is a language 
with high level syntax and low capabilities, as well as 
excellent performance and being open source.


Unnetworked personal mobile devices are the target platform for 
the standard implementation of OBI. A demonstration release is 
scheduled for the end of this month (September 2015). The 
demonstration release will comprehend English prose only, later 
releases will be able to process input from other languages, as 
well as sensory input.

OBI will be a mixture of open and closed source modules.

To God be the Glory.

Asame Obiomah


It's about time TempleOS got a bit of competition. The 
"consciously self-aware, morally judging OBI" VS. "the OS that 
talks with God". One of them might even cry (using the Emotions 
0.91d module and the optional lawn sprinkler attachment).

Re: Current state of GUI's

[motaito via Digitalmars-d]

On Friday, 4 September 2015 at 09:12:23 UTC, Chris wrote:
Don't give up yet. I've learned that a D GUI is not so 
important. There is a plethora of platforms and devices (mobile 
phones, tablets, PCs etc etc), so it's better not to get 
married to one particular UI. Keep your program GUI-agnostic 
and then you can connect it to any GUI you want. And D is easy 
to connect to: C(++), Lua (LuaD) and Python (PyD).


With D you can concentrate on the program, the GUI could be 
anything. E.g. look at how the DCD/Dscanner plug-in works with 
Textadept and other editors.


https://github.com/Hackerpilot/DCD/wiki/IDEs-and-Editors-with-DCD-support


At first I thought, yes your right. But on second thought that 
kind of brings me back to the initial question. I would prefer an 
integrated solution, so I don't have the hustle with 
dependencies. With your approach, I also have to maintain a 
dependency. E.g. if I choose PyD I also need to distribute it to 
the end user. I am not even sure, if I would also need to have 
python as separate dependency or if it's included in PyD. Either 
way while python may be common on Linux, it is not a standard on 
Windows. I have the same problem with something like GtkD. The 
Gtk Framework is common on Linux but not on windows. I don't have 
such issues with QT. There I have all in one package. All I have 
to do is include the required dll's. QT is also very common in 
many Linux distributions. So, I can just compile and give it to 
anyone who is interested without the hustle of more dependencies. 
BSD is certainly the most difficult to find a solution. Such a 
great OS so little support. But they too have QT. I was hoping to 
basically use QT with D instead of C++. Shannon made a post with 
an interesting approach. I think I will look more into that 
first. But thanks for the tip!

Re: Working Windows GUI library?

[Andre Polykanine via Digitalmars-d-learn]

Hello thedeemon,

tvDdl> Yes, DFL!
tvDdl> https://github.com/Rayerd/dfl

Sounds  good.  but still... I can't find any examples or documentation
:(

-- 
With best regards from Ukraine,
Andre
Skype: Francophile
Twitter: @m_elensule; Facebook: menelion
My blog: http://menelion.oire.org/


 Original message 
From: thedeemon via Digitalmars-d-learn 
To: digitalmars-d-learn@puremagic.com
Date created: , 9:30:34 AM
Subject: Working Windows GUI library?


  On Thursday, 3 September 2015 at 15:46:28 UTC, Andre Polykanine 
wrote:
> So  my  question  is:  is  there any reliable GUI library 
> implementing native Windows controls?

Yes, DFL!
https://github.com/Rayerd/dfl
It's a thin wrapper over WinAPI so all controls are native. I've 
built several apps with it and quite happy with this library. It 
comes with a graphical interface builder called Entice Designer 
which is rather old but still works fine. Also, with this lib 
your app is just a single binary less than 1 MB, no additional 
DLLs required.

[Issue 14959] Regression in HEAD: linker error on printing SysTime with writeln

[via Digitalmars-d-bugs]

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

--- Comment #10 from Vladimir Panteleev  ---
(In reply to Jack Stouffer from comment #9)
> Unfortunately, every time I try to use digger, the build fails even though
> github loads just fine in my browser:
> 
> Cloning into 'dmd'...
> fatal: unable to connect to github.com:
> github.com[0: 192.30.252.130]: errno=Operation timed out

Unblock TCP port 9418 or run:

git config --global url.https://github.com/.insteadOf git://github.com/

--

Re: dmd codegen improvements

[rsw0x via Digitalmars-d]

On Friday, 4 September 2015 at 13:39:45 UTC, Ola Fosheim Grøstad 
wrote:
On Friday, 4 September 2015 at 07:52:30 UTC, Ola Fosheim 
Grøstad wrote:
I have no problem recommending TypeScript with WebStorm (or 
some other editor) for business like applications.


Err... avoid WebStorm. Just noticed JetBrains have decided to 
rip off their customers with a subscription model and increase 
their pricing 100%. Damn, I'm going back to OpenSource IDEs…


I believe the FOSS version of Intellij can install the Javascript 
plugin which also adds support for Typescript.

May be wrong.

Re: Interesting user mistake

[Jonathan M Davis via Digitalmars-d]

On Friday, 4 September 2015 at 14:14:43 UTC, Mike James wrote:
On Friday, 4 September 2015 at 14:05:09 UTC, Jonathan M Davis 
wrote:
On Friday, 4 September 2015 at 13:55:03 UTC, Jonathan M Davis 
wrote:

[...]

[snip]

[...]


Isn't it called Maximal Munch...

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

Regards, --


Yes. That's how most languages typically parse tokens, but some 
programming languages are more willing to force formatting on you 
than others, even if they use maximal munch. You _can_ choose to 
make certain uses of whitespace illegal while still using maximal 
munch, since all that maximal munch is doing is deciding how 
you're going to know whether a sequence of characters is one 
token or several when it's ambiguous. It's why vector> has resulted in the C++98 parsers thinking that the >> on 
the end is a shift operator rather than the closing halves of the 
two templates, and C++11, Java, and C# have all had to _not_ use 
maximal munch in that particular case to make it so that it's not 
treated as the shift-operator. It makes their grammars that much 
less context-free and is part of why D uses !() for template 
instantiations.


In any case, I didn't use the term maximal munch, because that 
indicates how tokens are separated and says nothing about how you 
format your code (aside from the fact that you sometimes have to 
add whitespace to disambiguate if the grammar isn't clean 
enough), whereas this discussion really has to do with making 
formatting your code in a particular instance illegal (or at 
least that the compiler would warn about it, which is essentially 
equivalent to making it illegal, since no one should leave 
warnings in their code, and -w literally turns all warnings into 
errors anyway). There is no ambiguity as to whether =+ is the 
same as = + as far as the compiler is concerned, because there is 
no =+ token, and so maximal munch doesn't really even come into 
play here.


- Jonathan M Davis

[Issue 14959] Regression in HEAD: linker error on printing SysTime with writeln

[via Digitalmars-d-bugs]

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

--- Comment #14 from Vladimir Panteleev  ---
Terminal output. You can redirect it to a file e.g. with "2>&1 | tee
digger.log".

--

Re: dmd codegen improvements

[Jacob Carlborg via Digitalmars-d]

On 2015-09-04 15:39, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 wrote:



Err... avoid WebStorm. Just noticed JetBrains have decided to rip off
their customers with a subscription model and increase their pricing
100%. Damn, I'm going back to OpenSource IDEs…


I heard the TypeScript support for Visual Studio Code is really good.

--
/Jacob Carlborg

Re: Status of Win32 C++ interop

[Kagamin via Digitalmars-d-learn]

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

Re: Interesting user mistake

[Jonathan M Davis via Digitalmars-d]

On Friday, 4 September 2015 at 13:55:03 UTC, Jonathan M Davis 
wrote:
On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:

http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

The gist of it is the user wrote =+ instead of +=. I wonder if 
we should disallow during tokenization the sequence "=", "+", 
whitespace. Surely it's not a formatting anyone would aim for, 
but instead a misspelling of +=.

[snip]

Actually, I may have misunderstood the suggestion. I do _not_ 
think that we should require that someone who writes code like


a=+b;

should be forced to put whitespace in their code, as ugly as it 
arguably is that they don't (which is what I thought was being 
suggested). However, if they've written their code like


a =+ b;

then it would make sense to warn about it, since the odds of that 
being legitimate are nearly zero, and the same goes for any other 
unary operator. Someone might be weird and choose to put 
whitespace before the unary operator, but I don't think that 
that's very common, and if someone is doing that, they're not 
likely to then _not_ put a space before the unary operator. So, I 
don't think that we'd really be cramping anyone's style (be it 
ugly or otherwise) if we warned about =+ when there's whitespace 
on both sides of =+ but not between them.


Now, I tend to think that anything should either be an error or 
not and that everything else should be left to a linter, since 
it's subjective, so I'm still not a big fan about having 
something like this be a warning, but I very much doubt that 
it'll really cause any problems if it is, since I have a hard 
time believing that anyone is even going to _want_ to write


a =+ b;

- Jonathan M Davis

[Issue 14959] Regression in HEAD: linker error on printing SysTime with writeln

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

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

--- Comment #13 from Jack Stouffer  ---
(In reply to Vladimir Panteleev from comment #12)
> (In reply to Jack Stouffer from comment #11)
> > Works with digger build. I'm not quite sure what that means. Am I manually
> > building DMD wrong?
> 
> It means that the way in which Digger builds D and the way you build D
> result in different outcomes. You could look through Digger's log, see how
> it builds D and try to find the difference with your method.
> 
> It could also be an installation problem (mismatching versions of the
> compiler and Phobos, or Phobos library and Phobos source code, or an
> outdated version of one of the above being in front of the just-built
> version in the search path).

Because I am going to assume digger is more correct that my build I will close
this. Where can I find said log file?

--

Re: dmd codegen improvements

[rsw0x via Digitalmars-d]

On Thursday, 3 September 2015 at 22:53:01 UTC, deadalnix wrote:
On Thursday, 3 September 2015 at 21:08:51 UTC, Ola Fosheim 
Grostad wrote:

On Thursday, 3 September 2015 at 10:04:58 UTC, deadalnix wrote:
On Thursday, 3 September 2015 at 09:56:55 UTC, Ola Fosheim 
Grøstad wrote:
On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix 
wrote:

[...]


It is translatable to pure assembly, addressing is modulo 
heap size. Performance is a different issue since it does 
not provide SIMD yet.


SIMD is not even remotely close to explaining the perf 
difference.


What browser? Only FF supports it. Chrome just JIT it IIRC.


asm.js typically runs half the speed of natively compiled code. 
pNaCl run about 20% slower typically.


The gap is way to big for vectorization to be a reasonable 
explanation. In fact a large body of code just do not vectorize 
at all.


You seems to be fixated on that vectorization thing, when it is 
not even remotely close to the problem at hand.


All of this could have been avoided by all browser vendors 
agreeing to implement pNaCl.
Maybe we'll be lucky and Firefox will fade into obscurity with 
the way they've been handling things lately.

Re: Interesting user mistake

[immu via Digitalmars-d]

On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:
I wonder if we should disallow during tokenization the sequence 
"=", "+", whitespace. Surely it's not a formatting anyone would 
aim for, but instead a misspelling of +=.



Andrei



Please don't. That would feel like a completely arbitrary 
exception in the grammar.

Re: Containers

[wobbles via Digitalmars-d]

On Friday, 4 September 2015 at 10:25:24 UTC, Russel Winder wrote:
On Thu, 2015-09-03 at 21:11 +, bitwise via Digitalmars-d 
wrote:

On Thursday, 3 September 2015 at 19:45:48 UTC, bitwise wrote:

> I'm not sure how the container's I've built would be 
> integrated


I suppose what I'm suggesting would be to integrate my new 
containers and modify the spec to explain the new value type 
containers, and start deprecating the old containers as better 
versions become available...starting with Array(T)...


Or I could stop trying to make tangible contributions to D and 
just go bikeshed about =+


Isn't the best route here to make a trivially accessible 
library (via the Dub repository?) that people can choose to use 
instead of the bits of Phobos that these data structures 
replace? This will then allow the momentum of usage to apply 
pressure for the Phobos ones to be deprecated and your new ones 
to be absorbed into Phobos…


I do think this is the best option for all new libraries that are 
to be potentially merged into phobos.


It's how the python/Java world works too and I think they've done 
pretty well out of it.

Re: Casting away immutability

[Kagamin via Digitalmars-d-learn]

On Friday, 4 September 2015 at 09:05:07 UTC, Marc Schütz wrote:
Note that you can however achieve immutability by using a 
_private_ read-only mapping.


man pages say the behavior is unspecified.

Re: Interesting user mistake

[Mike James via Digitalmars-d]

On Friday, 4 September 2015 at 14:05:09 UTC, Jonathan M Davis 
wrote:
On Friday, 4 September 2015 at 13:55:03 UTC, Jonathan M Davis 
wrote:

[...]

[snip]

[...]


Isn't it called Maximal Munch...

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

Regards, --

Re: Status of Win32 C++ interop

[Benjamin Thaut via Digitalmars-d-learn]

On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut 
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner 
wrote:


What about 32bit phobos? Last time I checked (2.067) only x64 
was distributed.


You have to compile it yourself. Use the win64 makefile and 
replace the arch=64 with

arch=32mscoff.

For more details see here:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html


Ah so that didn't change. Did you try it? Do you run hybrid 
C++/D apps on Win (whether 32 or 64)?. Asking because last time 
I tried it (Win x64 tho) writeln() call from D side crashed app 
because stdio wasn't properly initialized even tho rt_init() 
was successful.


I am running hybrid D/C++ apps. I found it to work best when you 
give D the control over the main method, e.g. the program entry 
point should be in D land. Then simply call a C++ function from 
there to initialize your c++ stuff.


I'm currently even running hybrid C++/D apps with dlls. E.g. 
multiple D dlls + multiple C++ dlls loaded by a c++ main program. 
But to do that I have heavy compiler + runtime modifications 
which are not ready yet to do a PR for them.

Re: dmd codegen improvements

[via Digitalmars-d]

On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote:
Maybe we'll be lucky and Firefox will fade into obscurity with 
the way they've been handling things lately.


No. TurboFan is in Chrome with asm.js support.

Re: std.Stream.InputStream convenience functions

[Jonathan M Davis via Digitalmars-d]

On Friday, 4 September 2015 at 00:05:06 UTC, bitwise wrote:

Thoughts?


std.stream is on the chopping block and has been for years, and 
it was decided at dconf that we'd actually get rid of it now 
rather than just have it say in the documentation that it's going 
away. As I understand it, the only reason that it wasn't 
deprecated in 2.068 was because of some sort of issue with the PR 
that forced it to be delayed. But there's no point in making any 
improvements to it, because that code is not going to be around 
for much longer.


- Jonathan M Davis

Re: Interesting user mistake

[via Digitalmars-d]

On Friday, 4 September 2015 at 12:02:26 UTC, Steven Schveighoffer 
wrote:

On 9/3/15 5:59 PM, Brian Schott wrote:
On Thursday, 3 September 2015 at 17:17:26 UTC, Steven 
Schveighoffer wrote:
What about all other operations that may be typos from op= 
where op is

also a unary operator? e.g. =-


We'd have to special-case '*':

a=*b;



You could say the same thing for =-:

a=-b;

seems reasonable for someone who doesn't like whitespace. I 
think Andrei's rule was the token sequence must have whitespace 
after the operator in order to be rejected. So the above would 
be fine.


Vector!double p;
p.x=+ 0.27;
p.y=-11.91;
p.z=- 8.24;

Re: Current state of GUI's

[Jacob Carlborg via Digitalmars-d]

On 2015-09-04 15:23, motaito wrote:


BSD is certainly the most difficult to find a solution.


I tried compiling DWT on PC-BSD and it compile just if I remove one 
check for Linux. Although it doesn't link because I haven't managed to 
install the necessary libraries yet.


--
/Jacob Carlborg

Re: Interesting user mistake

[Jonathan M Davis via Digitalmars-d]

On Thursday, 3 September 2015 at 18:31:59 UTC, Meta wrote:

On Thursday, 3 September 2015 at 17:12:31 UTC, H. S. Teoh wrote:
Is there a way for the lexer to check for the specific 
character sequence '=', '+', whitespace and not others (e.g. 
'=', whitespace, '+')?  IOW, "a =+ b" will be prohibited, but 
"a = + b" will be allowed. If so, I agree with this.


On that note, though, the unary + operator is totally useless 
in D... maybe we should get rid of that instead?  (Then "=+" 
will automatically be an error.)



T


Worse than useless; it doesn't even behave as you would expect.

import std.stdio;

void main()
{
auto a = -1;
writeln(+a); //Prints -1
writeln(-a); //Prints  1
}

At least unary - does something.


I didn't realize that a unary + operator existed. I would have 
assumed that +a as an expression would be illegal. It doesn't 
even mean anything.


- Jonathan M Davis

Re: dmd codegen improvements

[via Digitalmars-d]

On Friday, 4 September 2015 at 07:52:30 UTC, Ola Fosheim Grøstad 
wrote:
I have no problem recommending TypeScript with WebStorm (or 
some other editor) for business like applications.


Err... avoid WebStorm. Just noticed JetBrains have decided to rip 
off their customers with a subscription model and increase their 
pricing 100%. Damn, I'm going back to OpenSource IDEs…

[Issue 14959] Regression in HEAD: linker error on printing SysTime with writeln

[via Digitalmars-d-bugs]

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

--- Comment #11 from Jack Stouffer  ---
(In reply to Vladimir Panteleev from comment #10)
> (In reply to Jack Stouffer from comment #9)
> > Unfortunately, every time I try to use digger, the build fails even though
> > github loads just fine in my browser:
> > 
> > Cloning into 'dmd'...
> > fatal: unable to connect to github.com:
> > github.com[0: 192.30.252.130]: errno=Operation timed out
> 
> Unblock TCP port 9418 or run:
> 
> git config --global url.https://github.com/.insteadOf git://github.com/

Works with digger build. I'm not quite sure what that means. Am I manually
building DMD wrong?

--

Re: Beta D 2.068.1-b2

[Jacob Carlborg via Digitalmars-d-announce]

On 2015-09-04 14:04, Martin Nowak wrote:


The problem is that you're hiding a method that is still reachable
through the vtable.
Rather than throwing a runtime error this was changed to a compiler error.

https://github.com/D-Programming-Language/dmd/pull/4606

You should not turn off deprecations btw ;).


I haven't turned off deprecations. This is in Tango and it seems no one 
has cared to fix those.



The simple solution in you case is to override the inherited `string
toString()` with an implementation that forwards to your `toString()`.

class UniText
{
 override string toString() { return toString(null).idup; }
 abstract const char[] toString (char[]  dst = null);
 abstract const wchar[] toString16 (wchar[] dst = null);
 abstract const dchar[] toString32 (dchar[] dst = null);
}

Also see at
https://github.com/D-Programming-Language/druntime/blob/4e799b75ebcb6d00ccefbcfd763a1f5d158357a1/src/object.d#L1598
for an example of an alternative overridable toString method.
Maybe you should use the delegate based toString as well, it's already
supported by a some phobos formatting.


Again, this is in Tango, I just want it to compile :)

--
/Jacob Carlborg

Re: dmd codegen improvements

[rsw0x via Digitalmars-d]

On Friday, 4 September 2015 at 14:34:52 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote:
Maybe we'll be lucky and Firefox will fade into obscurity with 
the way they've been handling things lately.


No. TurboFan is in Chrome with asm.js support.


I'd rather not advocate the adoption of inferior technology.

Re: dmd codegen improvements

[Manu via Digitalmars-d]

On 5 Sep 2015 12:32 am, "rsw0x via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On Thursday, 3 September 2015 at 22:53:01 UTC, deadalnix wrote:
>>
>> On Thursday, 3 September 2015 at 21:08:51 UTC, Ola Fosheim Grostad wrote:
>>>
>>> On Thursday, 3 September 2015 at 10:04:58 UTC, deadalnix wrote:

 On Thursday, 3 September 2015 at 09:56:55 UTC, Ola Fosheim Grøstad
wrote:
>
> On Thursday, 3 September 2015 at 06:18:54 UTC, deadalnix wrote:
>>
>> [...]
>
>
> It is translatable to pure assembly, addressing is modulo heap size.
Performance is a different issue since it does not provide SIMD yet.


 SIMD is not even remotely close to explaining the perf difference.
>>>
>>>
>>> What browser? Only FF supports it. Chrome just JIT it IIRC.
>>
>>
>> asm.js typically runs half the speed of natively compiled code. pNaCl
run about 20% slower typically.
>>
>> The gap is way to big for vectorization to be a reasonable explanation.
In fact a large body of code just do not vectorize at all.
>>
>> You seems to be fixated on that vectorization thing, when it is not even
remotely close to the problem at hand.
>
>
> All of this could have been avoided by all browser vendors agreeing to
implement pNaCl.
> Maybe we'll be lucky and Firefox will fade into obscurity with the way
they've been handling things lately.

What I don't get is, Firefox and ie support plugins... Why isn't there a
pnacl plugin for other browsers? Surely it could be added with the existing
plugin interfaces?

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

On 1/09/2015 11:57 PM, Rory McGuire via Digitalmars-d-announce wrote:

Surely this is a code coverage issue then?
Are there any unit tests  in ddmd?


There is an enormous test suite, but there are also plenty of parts with 
zero coverage.

Re: Interesting user mistake

[Jonathan M Davis via Digitalmars-d]

On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:

http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

The gist of it is the user wrote =+ instead of +=. I wonder if 
we should disallow during tokenization the sequence "=", "+", 
whitespace. Surely it's not a formatting anyone would aim for, 
but instead a misspelling of +=.


Well, in this particular case, wouldn't it make more sense to 
simply make + as a unary operator illegal? It doesn't even _do_ 
anything, and I, for one, didn't even know that such an operator 
existed before this thread.


In general though, I think that warning based on whitespace is a 
slippery slope, especially when the language is designed such 
that whitespace doesn't matter unless it's required to make it so 
that a compound token is separate tokens. And this particular 
case isn't even generalizable, because there are other operators 
where they _would_ go in that order, and if you don't actually 
want to properly space out your operators with whitespace, then 
you'll end up with stuff like =-a and =*a which are perfectly 
legitimate. So, we're forced to either special case =+, or we're 
essentially going to require that you put a space after =, and 
while I think that everyone should, that's basically requiring 
folks to format their code in a particular way which isn't in 
line with D or its C/C++ ancestry and the expectations of the 
developers who use such languages.


So, honestly, I'm more inclined to tell folks that maybe if they 
want their code to be clear and avoid mistakes like this, they 
should put whitespace around operators, but it's a free world, 
and they're free to format their code in a way that's harder to 
read and more likely to help them shoot themselves in the foot if 
they really want to.


But regardless, I question that even allowing + as a unary 
operator even makes sense in the first place. I guess that some 
folks might use it to try and make the difference between a 
positive and a negative number more obvious? But I would have 
thought that it would make it _harder_ to distinguish them rather 
than easier. So, maybe we can just get rid of the unary + 
operator. But still, that would only help this particular case, 
and other operators which _do_ make sense as unary operators to 
the right of an assignment still have the potential of being 
mistyped to painful results if programmers don't actually put 
whitespace around = like most of us would.


- Jonathan M Davis

[Issue 14959] Regression in HEAD: linker error on printing SysTime with writeln

[via Digitalmars-d-bugs]

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

--- Comment #9 from Jack Stouffer  ---
(In reply to Vladimir Panteleev from comment #8)
> Can you try building D with Digger?
> 
> https://github.com/CyberShadow/Digger

Unfortunately, every time I try to use digger, the build fails even though
github loads just fine in my browser:

Cloning into 'dmd'...
fatal: unable to connect to github.com:
github.com[0: 192.30.252.130]: errno=Operation timed out

Clone of 'git://github.com/D-Programming-Language/dmd' into submodule path
'dmd' failed
digger: Not caching build failure due to temporary/environment error.
Fatal error: Command ["git",
"--work-tree=/Users/Jack/dlang_contrib/test_dir/repo",
"--git-dir=/Users/Jack/dlang_contrib/test_dir/repo/.git", "submodule",
"update", "--init", "dmd"] failed with status 1

--

Re: dmd codegen improvements

[via Digitalmars-d]

On Friday, 4 September 2015 at 14:40:32 UTC, rsw0x wrote:
On Friday, 4 September 2015 at 14:34:52 UTC, Ola Fosheim 
Grøstad wrote:

On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote:
Maybe we'll be lucky and Firefox will fade into obscurity 
with the way they've been handling things lately.


No. TurboFan is in Chrome with asm.js support.


I'd rather not advocate the adoption of inferior technology.


It has already been adopted by Microsoft, Google and Mozilla...

Re: Beta D 2.068.1-b2

[Steven Schveighoffer via Digitalmars-d-announce]

On 9/4/15 8:14 AM, Steven Schveighoffer wrote:


Why did this compile/pass tests then? I wasn't aware of this restriction.

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


OK, I dug into it further.

It seems that under some level of detection of whether a function that 
could be called on the base is really called on the derived, then the 
derived function is not allowed to mask the base function.


HOWEVER, if the call would result in an error instead, then the override 
is totally fine, and calling the function on a base reference actually 
calls the masked function. This seems incorrect, when you mask a 
function, I would consider that to be hidden also.


So technically, the error is that the toString masking could be called 
in the same way the base could be called (given the default parameter).


This sure seems arbitrary to me. I remember the whole thing about 
function hijacking, but this hidden function "feature" doesn't make a 
lot of sense. In one case, you can hide it, but still access it from the 
base, in another, the compiler was rewriting the vtable to not allow you 
to access it from the base, on what seems to be an arbitrary concern. 
And that now is a compiler error.


I wonder how this will affect multiple alias this, since you could 
potentially have a type that converts to two disjoint types, but 
wouldn't be known to the compiler if a base and derived class accepted 
the disjoint types.


-Steve

Re: 1st Ever Artificial Consciousness to be Written in D Language

[tired_eyes via Digitalmars-d-announce]

Not really. A tabloid reader can be modeled like this:



Sounds like a plan. Going to make a website about it. Is this 
code patent-protected btw?

[Issue 14959] Regression in HEAD: linker error on printing SysTime with writeln

[via Digitalmars-d-bugs]

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

--- Comment #12 from Vladimir Panteleev  ---
(In reply to Jack Stouffer from comment #11)
> Works with digger build. I'm not quite sure what that means. Am I manually
> building DMD wrong?

It means that the way in which Digger builds D and the way you build D result
in different outcomes. You could look through Digger's log, see how it builds D
and try to find the difference with your method.

It could also be an installation problem (mismatching versions of the compiler
and Phobos, or Phobos library and Phobos source code, or an outdated version of
one of the above being in front of the just-built version in the search path).

--

Re: dmd codegen improvements

[Jonathan M Davis via Digitalmars-d]

On Thursday, 3 September 2015 at 01:54:45 UTC, Laeeth Isharc 
wrote:
On Tuesday, 1 September 2015 at 17:14:44 UTC, Jonathan M Davis 
wrote:
It's been mentioned before that there really isn't much point 
in using C when you can use D. Even if you completely avoid 
the GC and the standard library, you're _still_ ahead of where 
you'd be with C, and you can call C functions trivially. So, 
you can definitely use D as a better C; you just lose out on a 
lot of cool stuff that D has to offer beyond that. But D has a 
lot to offer over C even without using any of that stuff.


One of the first projects I used D for was back in college a 
number of years ago where I got sick of some of the issues I 
was having with C++ and went with D because it gave me stuff 
like array bounds checking. I was using very few of D's 
features (heck, D2 was quite young at that point, and I don't 
think that ranges had been introduced to Phobos yet at that 
point, so the standard library was seriously lacking anyway), 
but it was still easier to use D.


- Jonathan M Davis



worthy of a quick blogpost sometime?  Laeeth.


My memory would be pretty sketchy on it at this point. I remember 
what the project was (it had to do with randomly generating 3D 
fractals in opengl for a graphics course), but that was back in 
2008, I think, and I couldn't really say much interesting about 
it beyond the fact that I was annoyed enough with C++ at the time 
to use D for the project. The only thing notable about it is that 
it was the first thing that I did in D that was actually supposed 
to do something rather than just messing around with the language.


- Jonathan M Davis

Re: A Small Enhancement Idea

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 2 September 2015 at 19:34:53 UTC, Jack Stouffer 
wrote:

On Wednesday, 2 September 2015 at 19:15:08 UTC, jmh530 wrote:
I wasn't familiar with version(release). Would you need to 
compile with -version=release then?


No, it seems to work with just the -release flag.

The Python programmer in me hates the inconsistency between 
these two, but it's fine.


It's because -debug has _nothing_ to do with "debug mode." It 
simply has to do with debugging. And that makes sense and is 
perfectly fine except that it causes confusion when you start 
considering -release and "release mode" - especially when folks 
have a tendency to call the opposite of "release mode" "debug 
mode." So, arguably -debug and version(debug) should have been 
something else in order to reduce confusion, but I honestly don't 
know what name to use instead, since it _is_ specifically for 
debugging.


- Jonathan M Davis

Re: dmd codegen improvements

[rsw0x via Digitalmars-d]

On Friday, 4 September 2015 at 14:53:06 UTC, Manu wrote:
On 5 Sep 2015 12:32 am, "rsw0x via Digitalmars-d" < 
digitalmars-d@puremagic.com> wrote:

[...]

wrote:

[...]
Performance is a different issue since it does not provide SIMD 
yet.

[...]

run about 20% slower typically.

[...]

In fact a large body of code just do not vectorize at all.

[...]

remotely close to the problem at hand.

[...]

implement pNaCl.

[...]

they've been handling things lately.

What I don't get is, Firefox and ie support plugins... Why 
isn't there a pnacl plugin for other browsers? Surely it could 
be added with the existing plugin interfaces?


Mozilla flat out stated they have no intention of supporting 
pNaCl. I'm sure a third party could make a plugin to support it.

Re: Status of Win32 C++ interop

[Laeeth Isharc via Digitalmars-d-learn]

On Friday, 4 September 2015 at 14:18:40 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner 
wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut 
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner 
wrote:


What about 32bit phobos? Last time I checked (2.067) only 
x64 was distributed.


You have to compile it yourself. Use the win64 makefile and 
replace the arch=64 with

arch=32mscoff.

For more details see here:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html


Ah so that didn't change. Did you try it? Do you run hybrid 
C++/D apps on Win (whether 32 or 64)?. Asking because last 
time I tried it (Win x64 tho) writeln() call from D side 
crashed app because stdio wasn't properly initialized even tho 
rt_init() was successful.


I am running hybrid D/C++ apps. I found it to work best when 
you give D the control over the main method, e.g. the program 
entry point should be in D land. Then simply call a C++ 
function from there to initialize your c++ stuff.


I'm currently even running hybrid C++/D apps with dlls. E.g. 
multiple D dlls + multiple C++ dlls loaded by a c++ main 
program. But to do that I have heavy compiler + runtime 
modifications which are not ready yet to do a PR for them.


Hi Benjamin

Would you be able to give a little more colour on what the limits 
are of interoperability for C++ with DMD master or release ?  As 
I understand it destructors and constructors don't work, and 
obviously it will get tricky passing structures and classes from 
C++ libraries not ported to D.


Reason I ask is I am about to make a case to someone as to why we 
should use D, and I don't want to make any unfounded claims.  I 
don't really know C++ myself, although my noddy test worked fine.


Thanks - and we should bring the doc page IP to date.  At least 
say that more works than currently described, as I am sure this 
will be a factor in adoption.



Laeeth.

Re: dmd codegen improvements

[Andrei Alexandrescu via Digitalmars-d]

On 09/02/2015 11:57 PM, Walter Bright wrote:

On 9/2/2015 7:48 PM, Adam D. Ruppe wrote:

but still i'm meh on the practical usefulness of such things. I guess
if you
target a canvas and run your code in it that makes more sense but my
preferred
style is a progressive enhancement webpage where you want to know the
browser
platform and work with it rather than around it.


I don't see a whole lot of point to generating JS from another language.
You can't do anything more than JS can do, and you're likely to be doing
less.



The premise here is that Javascript is a lock-in for code that can run 
in the browser. So to get D code to run in the browser you'd need to 
generate Javascript. This concern is orthogonal to relative capabilities 
of languages etc. -- Andrei

Re: dmd codegen improvements

[via Digitalmars-d]

On Friday, 4 September 2015 at 14:45:39 UTC, rsw0x wrote:
Because it has the path of least resistance. It's still a poor 
technology that is just treating the symptoms.


pnacl/pepper is not good either, they are both poor technologies.

But vendors are moving in the same direction, which is important, 
and compilers are improving each release. What matters most is 
getting something that is 3x+ faster than javascript when you 
need it, cross browser. Fortunately, Apple seems to take is 
seriously too, which is important, iOS Safari is a critical 
platform.

Re: dmd codegen improvements

[via Digitalmars-d]

On Friday, 4 September 2015 at 14:59:12 UTC, Ola Fosheim Grøstad 
wrote:
Actually, browsers are deprecating NPAPI plugins. Flash is so 
dead…


Could, in principle, Flash be supported through an extension, 
instead of a media / NPAPI plugin?

Re: Call a function passed as template parameter.

[moechofe via Digitalmars-d-learn]

On Thursday, 3 September 2015 at 13:16:41 UTC, Adam D. Ruppe 
wrote:

http://arsdnet.net/dcode/book/chapter_08/11/caller.d
https://github.com/adamdruppe/arsd/blob/master/jsvar.d#L608


Thank you for these examples.

Re: "else if" for template constraints

[Enamex via Digitalmars-d]

On Friday, 4 September 2015 at 15:52:08 UTC, Enamex wrote:
The biggest problem, I think, is that a template can has 
multiple 'predicates' to agree to be instantiated, but only 
some of them can mutually exclusive (the specialization syntax 
produces mutually exclusive ones, the if-constraints don't).

[...]
template Bar(T) {
static if( is(T == int) || is(T == string) || ... ) {
//stuff
}
else static if( stuff ) {
// other stuff
}
else {
template return; // I know my T took whatever your type 
was but I actually don't match, please exclude me from your 
list for this instance...

}
}
[...]


On second thought, it wouldn't help as much as I'd thought with 
overloading problems. What we want is a 'which template has more 
'&&'ed expressions in its constraint?' which sounds pretty awful. 
I have no idea how this could work :/


Especially given that D's constraints are way more open than, 
say, Haskell's, in their checking; though ironically not their 
declaration/implementation (D is open because it checks for 
structural conformance of a struct instead of nominative & 
structural; but it's more restricted because it easily only 
checks for structure of the type as declared, with no way to 
attach recognized-to-the-constraint ad-hoc interfaces to a type 
like Haskell's with type-classes).

Re: dmd codegen improvements

[Andrei Alexandrescu via Digitalmars-d]

On 09/03/2015 02:54 AM, Walter Bright wrote:

On 9/2/2015 9:09 PM, H. S. Teoh via Digitalmars-d wrote:

As Walter once said, "Be the change you wish to see."


I think that was Andrei. But I do agree with it.


I think it was Gandhi :o). -- Andrei

Re: dmd codegen improvements

[rsw0x via Digitalmars-d]

On Friday, 4 September 2015 at 14:43:43 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 4 September 2015 at 14:40:32 UTC, rsw0x wrote:
On Friday, 4 September 2015 at 14:34:52 UTC, Ola Fosheim 
Grøstad wrote:

On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote:
Maybe we'll be lucky and Firefox will fade into obscurity 
with the way they've been handling things lately.


No. TurboFan is in Chrome with asm.js support.


I'd rather not advocate the adoption of inferior technology.


It has already been adopted by Microsoft, Google and Mozilla...


Because it has the path of least resistance. It's still a poor 
technology that is just treating the symptoms.

Re: Status of Win32 C++ interop

[Szymon Gatner via Digitalmars-d-learn]

On Friday, 4 September 2015 at 14:18:40 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner 
wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut 
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner 
wrote:


What about 32bit phobos? Last time I checked (2.067) only 
x64 was distributed.


You have to compile it yourself. Use the win64 makefile and 
replace the arch=64 with

arch=32mscoff.

For more details see here:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html


Ah so that didn't change. Did you try it? Do you run hybrid 
C++/D apps on Win (whether 32 or 64)?. Asking because last 
time I tried it (Win x64 tho) writeln() call from D side 
crashed app because stdio wasn't properly initialized even tho 
rt_init() was successful.


I am running hybrid D/C++ apps. I found it to work best when 
you give D the control over the main method, e.g. the program 
entry point should be in D land. Then simply call a C++ 
function from there to initialize your c++ stuff.


I'm currently even running hybrid C++/D apps with dlls. E.g. 
multiple D dlls + multiple C++ dlls loaded by a c++ main 
program. But to do that I have heavy compiler + runtime 
modifications which are not ready yet to do a PR for them.


Hmm that is very good to hear, as is promising. In the mean time 
I tired making tiny Win x64 C++/D app as described by A.Ruppe in 
his book (I did that also when it was released and stdio was 
crashing apps) but now using phobos64.lib from 2.068 distribution 
does not even link properly with VC2015. Oh well, not just yet I 
suppose.


Thanks for your assistance!

Re: Possible solution for export : `unittest export`?

[deadalnix via Digitalmars-d]

On Friday, 4 September 2015 at 16:26:15 UTC, Andrei Alexandrescu 
wrote:

On 09/02/2015 05:07 PM, deadalnix wrote:
On Wednesday, 2 September 2015 at 09:28:49 UTC, Dominikus 
Dittes Scherkl

wrote:

It is not unitestable.
But we have concepts like "thread local per default" and 
message

passing that should make avoiding race conditions easier. And
concurrent code doesn't prevent us from testing all paths of 
templates.


I was responding to the statement that you should unittest 
everything.


That is simply not true. For some code, this is not possible, 
for some

other code, it gives poor noise to signal ratio.


What would be a good litmus test "this code needs/doesn't need 
unittesting"? -- Andrei


IMO, is the test going to be reliable or break easily is probably 
the most important parameter. You want unitests to have a high 
noise to signal ratio so they can be part of the build and/or run 
on every PR.


There is obviously a grey area where reasonable people will 
disagree on the cost benefit ratio.


A good litmus test would be "is there a lot of parameter that 
aren't under my control that affect this piece of code ?"

[Issue 14673] BigInt needs more performance and total revision

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

   Keywords||performance
 CC||j...@jackstouffer.com

--

Re: Interesting user mistake

[Steven Schveighoffer via Digitalmars-d]

On 9/4/15 10:05 AM, Jonathan M Davis wrote:

On Friday, 4 September 2015 at 13:55:03 UTC, Jonathan M Davis wrote:

On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei Alexandrescu wrote:

http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang


The gist of it is the user wrote =+ instead of +=. I wonder if we
should disallow during tokenization the sequence "=", "+",
whitespace. Surely it's not a formatting anyone would aim for, but
instead a misspelling of +=.

[snip]

Actually, I may have misunderstood the suggestion. I do _not_ think that
we should require that someone who writes code like

a=+b;

should be forced to put whitespace in their code, as ugly as it arguably
is that they don't (which is what I thought was being suggested).
However, if they've written their code like

a =+ b;

then it would make sense to warn about it, since the odds of that being
legitimate are nearly zero, and the same goes for any other unary
operator.


I think that is Andrei's original suggestion:

the sequence "=", "+", whitespace should be rejected.

He says nothing about "=","+" without the whitespace.

-Steve

Re: Current state of GUI's

[Chris via Digitalmars-d]

On Friday, 4 September 2015 at 13:23:47 UTC, motaito wrote:

On Friday, 4 September 2015 at 09:12:23 UTC, Chris wrote:
Don't give up yet. I've learned that a D GUI is not so 
important. There is a plethora of platforms and devices 
(mobile phones, tablets, PCs etc etc), so it's better not to 
get married to one particular UI. Keep your program 
GUI-agnostic and then you can connect it to any GUI you want. 
And D is easy to connect to: C(++), Lua (LuaD) and Python 
(PyD).


With D you can concentrate on the program, the GUI could be 
anything. E.g. look at how the DCD/Dscanner plug-in works with 
Textadept and other editors.


https://github.com/Hackerpilot/DCD/wiki/IDEs-and-Editors-with-DCD-support


At first I thought, yes your right. But on second thought that 
kind of brings me back to the initial question. I would prefer 
an integrated solution, so I don't have the hustle with 
dependencies. With your approach, I also have to maintain a 
dependency. E.g. if I choose PyD I also need to distribute it 
to the end user. I am not even sure, if I would also need to 
have python as separate dependency or if it's included in PyD. 
Either way while python may be common on Linux, it is not a 
standard on Windows. I have the same problem with something 
like GtkD. The Gtk Framework is common on Linux but not on 
windows. I don't have such issues with QT. There I have all in 
one package. All I have to do is include the required dll's. QT 
is also very common in many Linux distributions. So, I can just 
compile and give it to anyone who is interested without the 
hustle of more dependencies. BSD is certainly the most 
difficult to find a solution. Such a great OS so little 
support. But they too have QT. I was hoping to basically use QT 
with D instead of C++. Shannon made a post with an interesting 
approach. I think I will look more into that first. But thanks 
for the tip!


I see what you mean. As far as I know, the libraries (PyD, LuaD 
etc.) would be in the static build of the executable, so you 
wouldn't have to "distribute" them, only Python or Lua. But 
that's no problem either, just include lua5.x.so/dll. Please 
guys, correct me, if I'm wrong here, I don't wanna give motaito 
any wrong information.


This said, the GUI should only be a very very thin layer on top 
of your actual program, regardless. What if your users say that 
they want a different GUI (Mac users for example, they don't 
accept anything that is a bit different), or the D-GUI doesn't 
work on a given OS for some reason, or a new GUI is introduced 
with a new OS. That's why I said that your program should never 
get married to a specific GUI.

[Issue 14975] DMD refuses to inline even trivial struct constructors

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

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

--

[Issue 14975] DMD refuses to inline even trivial struct constructors

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/545572134f613433f0efe3aaa247b3f401a02aa9
fix Issue 14975 - DMD refuses to inline even trivial struct constructors

https://github.com/D-Programming-Language/dmd/commit/68650c1df4608a10be47e5cfe0610babe7bd2f47
Merge pull request #5033 from WalterBright/fix14975

fix Issue 14975 - DMD refuses to inline even trivial struct constructors

--

Re: Interesting user mistake

[via Digitalmars-d]

On Friday, 4 September 2015 at 15:13:08 UTC, Steven Schveighoffer 
wrote:

I think that is Andrei's original suggestion:

the sequence "=", "+", whitespace should be rejected.

He says nothing about "=","+" without the whitespace.


Yup.

Re: dmd codegen improvements

[deadalnix via Digitalmars-d]

On Friday, 4 September 2015 at 14:43:43 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 4 September 2015 at 14:40:32 UTC, rsw0x wrote:
On Friday, 4 September 2015 at 14:34:52 UTC, Ola Fosheim 
Grøstad wrote:

On Friday, 4 September 2015 at 14:26:49 UTC, rsw0x wrote:
Maybe we'll be lucky and Firefox will fade into obscurity 
with the way they've been handling things lately.


No. TurboFan is in Chrome with asm.js support.


I'd rather not advocate the adoption of inferior technology.


It has already been adopted by Microsoft, Google and Mozilla...


Doesn't mean it is not inferior. In fact it is bad enough on its 
own so there is the whole WebAssembly things going on.

Re: A Small Enhancement Idea

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 2 September 2015 at 16:28:12 UTC, Jack Stouffer 
wrote:
I wanted some second opinions on an idea I had for D before I 
made a bugzilla issue.


Currently in D, to have a statement run only in debug mode, you 
can mark it with the debug keyword. But, there is currently no 
way to mark a statement so that it only runs in release. So 
what I propose is a release statement like so:


debug {
// only runs when -debug is given
}

release {
// only runs when -release is given
}

Or, if adding a new keyword to the language is a no go, it 
could be done like so:


debug {
// only runs when -debug is given
} else {
// only runs when -release is given
}

I have run into a need for this twice in one day, both having 
to do with unit tests in phobos. For the first one, I needed a 
way to make sure that a function is @nogc in release. For the 
other, the function I was tested had different outputs for 
release and debug if the input was an empty range, and I had no 
way to test both cases.


I can think of several other use cases off the top of my head. 
One, If you have a GUI application that checks for a serial 
number on startup, there's no reason to do that check in a 
debug build. Or, if your making a game, there's no reason to do 
the opening logo crawl before the menu if your using debug mode.


A rebuttal to this might be to just use version and pass 
something in during compilation. The problem that I have is 
this is not a solution for the phobos code that I am working 
on. Also, I think the first example above is very clear code 
and follows the debug statement's precedent.


In general, it's a really _bad_ idea to only do something in 
release mode. It makes it much harder to debug it when something 
goes wrong, and it means that what you're doing in non-release 
mode doesn't necessarily correspond to what happens in release 
mode. Normally, the only code differences between release mode 
and non-release mode relate to extra correctness checking - like 
with assertions - which get stripped out in release mode for 
efficiency. And many folks think that even _that_ is a bad idea.


So, I'd suggest that you reconsider even trying to do this, and 
doing something like having a range act differently between 
release and non-release modes seems like a disaster waiting to 
happen. At most, having assertions that get stripped out in 
release mode makes sense. The behavior and semantics of the code 
doesn't really change in that case. It's just a question of what 
happens when you screw up and fail the assertion (i.e. whether 
it's triggered and kills your program or whether it was compiled 
out and your program heads into undefined, buggy territory).


So, maybe you've actually found a case where it makes sense to do 
something in release mode but not in non-release mode, but I 
seriously question that it's a good idea.


- Jonathan M Davis

Re: "else if" for template constraints

[Enamex via Digitalmars-d]

On Monday, 17 August 2015 at 13:18:43 UTC, Steven Schveighoffer 
wrote:
I was just looking at fixing this 
bug:https://issues.dlang.org/show_bug.cgi?id=14925


[...]

How often are you writing overloaded templates, and you want to 
say "if it doesn't match anything else, do this"? I'd love to 
see some form of syntax that brings template constraints in 
line with tried-and-true if/else statements.


One way to do this is to lexically order the if constraints, 
and if any of them start with "else", then they are mutually 
exclusive with the immediately preceding constraint for the 
same symbol (just like normal else).


So for example, you'd have:

void replaceInPlace(T, Range)(ref T[] array, size_t from, 
size_t to, Range stuff)

if(isDynamicArray!Range &&
is(Unqual!(ElementEncodingType!Range) == T) &&
!is(T == const T) &&
!is(T == immutable T))
{ /* version 1 that tries to write into the array directly */ }

void replaceInPlace(T, Range)(ref T[] array, size_t from, 
size_t to,

Range stuff)
else if(is(typeof(replace(array, from, to, stuff
{ /* version 2, which simply forwards to replace */ }

looks much better IMO. Can we do something like this? I'm not a 
compiler guru, so I defer to you experts out there.


-Steve


The biggest problem, I think, is that a template can has multiple 
'predicates' to agree to be instantiated, but only some of them 
can mutually exclusive (the specialization syntax produces 
mutually exclusive ones, the if-constraints don't).


Thinking about it from this angle, I believe the most flexible 
and sensible solution would be to support a sort of "early 
return" from a template. Thus:


template Bar(T) {
static if( is(T == int) || is(T == string) || ... ) {
//stuff
}
else static if( stuff ) {
// other stuff
}
else {
template return; // I know my T took whatever your type 
was but I actually don't match, please exclude me from your list 
for this instance...

}
}

template Bar(T) {
static if( is(T == float) || is(T == int[]) || ... ) {
// Bar!float/Bar!(int[]) stuff
}
else static if( OTHER_OTHER_stuff ) {
// other other stuff
}
else {
template return; // I know my T took whatever your type 
was but I actually don't match, please exclude me from your list 
for this instance...

}
}

Re: Possible solution for export : `unittest export`?

[Andrei Alexandrescu via Digitalmars-d]

On 09/02/2015 05:07 PM, deadalnix wrote:

On Wednesday, 2 September 2015 at 09:28:49 UTC, Dominikus Dittes Scherkl
wrote:

It is not unitestable.

But we have concepts like "thread local per default" and message
passing that should make avoiding race conditions easier. And
concurrent code doesn't prevent us from testing all paths of templates.


I was responding to the statement that you should unittest everything.

That is simply not true. For some code, this is not possible, for some
other code, it gives poor noise to signal ratio.


What would be a good litmus test "this code needs/doesn't need 
unittesting"? -- Andrei

Re: Status of Win32 C++ interop

[Kagamin via Digitalmars-d-learn]

On Friday, 4 September 2015 at 15:43:44 UTC, Szymon Gatner wrote:
but now using phobos64.lib from 2.068 distribution does not 
even link properly with VC2015.


That's https://issues.dlang.org/show_bug.cgi?id=14849

Re: Interesting user mistake

[skoppe via Digitalmars-d]

On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:

http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

The gist of it is the user wrote =+ instead of +=. I wonder if 
we should disallow during tokenization the sequence "=", "+", 
whitespace. Surely it's not a formatting anyone would aim for, 
but instead a misspelling of +=.



Andrei


Seems like a really, really small fish to catch. I wouldn't want 
to litter my codebase with those kind of rules.


Besides, isn't stackoverflow about the answers and opinions, 
rather than about the questions?

Re: Beta D 2.068.1-b2

[Kapps via Digitalmars-d-announce]

On Friday, 4 September 2015 at 11:44:44 UTC, BBasile wrote:


What's so different with C# 'new' that not to call 'super' in a 
D overriden method ? (even if C# has itself 'base' instead of 
'super')


C#
---
public class BaseC
{
public int x;
public void Invoke() { }
}
public class DerivedC : BaseC
{
new public void Invoke() { }
}
---

D
---
class BaseC
{
int x;
void Invoke() { }
}
class DerivedC : BaseC
{
override void Invoke() { /*super.Invoke() not called*/ }
}
---

apart from a compiler warning 
(https://msdn.microsoft.com/en-us/library/ms173153.aspx=


It is just a warning, because it's ultimately there to warn you 
of something you may not have noticed.

For example:

abstract class BaseA {
abstract void foo();
}

class A : BaseA {
override void foo() { }
virtual void foobar() { }
}

All is well.
But then BaseA (which may be in a different library), suddenly 
becomes:


abstract class BaseA {
abstract void foo();
virtual void foobar() { dostuff(); }
}

Now you have A, which has foobar, but isn't actually related to 
BaseA.foobar. You probably didn't mean to override foobar, but 
it's still confusing for anything expecting BaseA.foobar to be 
related to A.foobar. You might not even know BaseA.foobar was 
added if it was part of a different library. Or, even worse:


class B : A {
override void foobar() {
dootherstuff();
}
}

It definitely gets a bit odd, and new is there just to prevent 
confusion / clarify intentions, as well as let you know when a 
new method is added with the same name. The whole situation is 
messy, like what happens when A.foobar is removed and you 
suddenly start overriding BaseA.foobar instead. Or what if you 
were intending to override BaseA.foobar, but now you're suddenly 
overriding A.foobar once A adds the method? I'd actually prefer 
to specifically have to write 'override void A.foobar()' if 
A.foobar is marked as 'new' for this reason and make it an error 
to not include new or override when dealing with the same name. D 
could probably benefit from this approach as well, for the same 
reasons.

Re: Interesting user mistake

[Andrei Alexandrescu via Digitalmars-d]

On 09/03/2015 01:08 PM, H. S. Teoh via Digitalmars-d wrote:

On Thu, Sep 03, 2015 at 12:46:29PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:

http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

The gist of it is the user wrote =+ instead of +=. I wonder if we
should disallow during tokenization the sequence "=", "+", whitespace.
Surely it's not a formatting anyone would aim for, but instead a
misspelling of +=.

[...]

Is there a way for the lexer to check for the specific character
sequence '=', '+', whitespace and not others (e.g. '=', whitespace,
'+')?  IOW, "a =+ b" will be prohibited, but "a = + b" will be allowed.
If so, I agree with this.


Yah, space is relevant there. That's why the check is easiest done 
during tokenization. -- Andrei

Re: Interesting user mistake

[Andrei Alexandrescu via Digitalmars-d]

On 09/03/2015 01:15 PM, "Luís Marques   wrote:

On Thursday, 3 September 2015 at 17:12:31 UTC, H. S. Teoh wrote:

Is there a way for the lexer to check for the specific character
sequence '=', '+', whitespace and not others (e.g. '=', whitespace,
'+')?  IOW, "a =+ b" will be prohibited, but "a = + b" will be
allowed. If so, I agree with this.

On that note, though, the unary + operator is totally useless in D...
maybe we should get rid of that instead?  (Then "=+" will
automatically be an error.)


What about the generalization? E.g., '=', '-', whitespace?


Yah, '-' with the wrong spacing around it also makes sense. -- Andrei

Re: spawn X different workers & wait for results from all of them

[Justin Whear via Digitalmars-d-learn]

On Thu, 03 Sep 2015 18:50:21 +0200, Robert M. Münch wrote:

> Hi, I'm not sure how to best implement the following:
> 
> 1. I have 4 different tasks to do.
> 2. All can run in parallel 3. Every task will return some result that I
> need
> 
> Now how to best do it? When using receive() it fires on the first hit
> and the function continues. It's like a receive(OR), one hit and it's
> done. So, I would need something like a receive(ALL) that continues only
> of all results (messages) have been received.
> 
> Is something like this available or do I have to build it myself?

How would receive know?  If you're using std.concurrency, the receiving 
function needs to encode doneness, e.g.

const numJobs = 4;
foreach (_; 0 .. numJobs)
receive(...);

Or you could use std.parallelism:

foreach (pieceOfWork; parallel(listOfWork))
doIt(pieceOfWork);

Re: Interesting user mistake

[Observer via Digitalmars-d]

On Thursday, 3 September 2015 at 17:15:25 UTC, Enamex wrote:
On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:
we should disallow during tokenization the sequence "=", "+", 
whitespace. Surely it's not a formatting anyone would aim for, 
but instead a misspelling of +=.


Wasn't the original design for these operators in whichever 
language started them actually the swapped form? In any case, 
I'd personally choose to warn against any operator sequence 
without separating whitespaces if the sequence isn't in fact 
one operator (like "=!" (non-warn: "= !") vs "!=", and "=&", 
and a lot others, given operator overloading).


The += operator originally appeared in C, as the =+ operator 
(K, 1/e, p212, "Anachronisms").  Not long afterward, the 
ambiguity of a=+b became apparent, along with the obvious need to 
change the language to resolve the problem.  The issue was dealt 
with over several successive releases of the compiler:


(1) =+ operator is available (original compiler)
(2) =+ and += are both available (I'm not sure whether this step 
existed)
(3) =+ and += are both available; =+ produces a deprecation 
warning
(4) += is available; =+ now produces either a warning/error or 
just changes meaning, not sure which


I don't recall now where I read about that sequence of steps, and 
a quick, incomplete scan of my library doesn't yield it up so I 
could be more precise.  Nonetheless, that's how the transition 
happened.  The Rationale for the original ANSI C (X3.159-1989) 
mentions that =op forms have been dropped, and that in a Quiet 
Change, "expressions of the form x=-3 change meaning with the 
loss of the old-style assignment operators".  Which I suppose 
implies that the Standard itself doesn't require a warning 
message, though presumably high-quality compilers would be free 
to implement one.


K C did not contain a unary + operator (K, 1/e, p. 37, 
Section 2.5).  It was added by the first ANSI C, "for symmetry 
with unary -" (K, 2/e, p204, Section A7.4.4).  "An integral 
operand undergoes integral promotion."


In terms of compiler quality, we have a long history of compilers 
generating warning messages for legal but questionable 
constructions.  The first one that comes quickly to mind is GCC 
complaining about "if(a=b)":


warning: suggest parentheses around assignment used as truth 
value [-Wparentheses]


The notion here is that a common mistake is handled by:

(a) being warned about, when warnings are enabled (at least, by 
-Wall in GCC)

(b) having an alternate construction suggested (e.g., "if((a=b))")
(c) having a specific compiler flag to control generation of each 
such warning

Re: Working Windows GUI library?

[thedeemon via Digitalmars-d-learn]

On Friday, 4 September 2015 at 13:54:25 UTC, Andre Polykanine 
wrote:

Hello thedeemon,

tvDdl> Yes, DFL!
tvDdl> https://github.com/Rayerd/dfl

Sounds  good.  but still... I can't find any examples or 
documentation :(


Here's some original docs and examples:
http://wiki.dprogramming.com/Dfl/Tutorial
http://wiki.dprogramming.com/Dfl/HomePage

Documentation is a bit scarce, but if you're familiar with 
WinForms (from .NET) you'll recognize everything immediately and 
will feel at home with DFL.


Here's a real world sample - an app I made for our clients:
https://bitbucket.org/thedeemon/autovideoenhance
For instance, a simple typical form (window) code:
https://bitbucket.org/thedeemon/autovideoenhance/src/b0259ca763577cb50169eaa7ee99f074da21724d/folderform.d?at=default
(most of the big setup code is generated by Entice Designer, not 
written manually)

Re: Behavior of opEquals

[H. S. Teoh via Digitalmars-d]

On Fri, Sep 04, 2015 at 07:10:25PM +, Jonathan M Davis via Digitalmars-d 
wrote:
> On Thursday, 3 September 2015 at 13:05:49 UTC, Steven Schveighoffer wrote:
> >On 9/2/15 2:57 PM, Jacob Carlborg wrote:
> >
> >>In this case the solution/workaround is to explicitly call
> >>super.opEquals, but that will miss some optimizations implemented in
> >>object.opEquals.
> >
> >Those optimizations have already been exploited by the time you get
> >to Foo.opEquals, so I wouldn't worry about that.
> >
> >However, the avoidance of casting would be a good goal. One of the
> >things I don't like about the current == implementation for objects
> >is it cannot take any advantage of type knowledge at the call site.
> 
> Every time I've tried to templatize the free function opEquals, [...]
[...]

Wait, wait, did I miss something? Since when was operator overloading
allowed as free functions? Or is opEquals a special case?


T

-- 
If it tastes good, it's probably bad for you.

Re: dmd codegen improvements

[Laeeth Isharc via Digitalmars-d]

On Friday, 4 September 2015 at 14:22:17 UTC, Jonathan M Davis 
wrote:
On Thursday, 3 September 2015 at 01:54:45 UTC, Laeeth Isharc 
wrote:
On Tuesday, 1 September 2015 at 17:14:44 UTC, Jonathan M Davis 
wrote:
One of the first projects I used D for was back in college a 
number of years ago where I got sick of some of the issues I 
was having with C++ and went with D because it gave me stuff 
like array bounds checking. I was using very few of D's 
features (heck, D2 was quite young at that point, and I don't 
think that ranges had been introduced to Phobos yet at that 
point, so the standard library was seriously lacking anyway), 
but it was still easier to use D.


- Jonathan M Davis



worthy of a quick blogpost sometime?  Laeeth.


My memory would be pretty sketchy on it at this point. I 
remember what the project was (it had to do with randomly 
generating 3D fractals in opengl for a graphics course), but 
that was back in 2008, I think, and I couldn't really say much 
interesting about it beyond the fact that I was annoyed enough 
with C++ at the time to use D for the project. The only thing 
notable about it is that it was the first thing that I did in D 
that was actually supposed to do something rather than just 
messing around with the language.


- Jonathan M Davis


Tku for colour.

Re: Detecting premature end of spawned threads with std.concurrency

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/3/15 5:20 PM, Matt Kline wrote:

TDPL suggests that calls to std.concurrency.send will fail with an
"OwnedTerminated" or "OwnedFailed" exception if the destination thread
has exited, but neither the docs nor the current Phobos implementation
make any mention of such exceptions. Thinking the information was just
outdated, I searched the Git history of Phobos for such types, but found
nothing.

What are current best practices for determining if a child thread has
died? And should these types be added to TDPL errata?


It seems this is not handled.

Looking here:

https://github.com/D-Programming-Language/phobos/blob/master/std/concurrency.d#L506

spawn creates the thread, then calls the function, but never sets a flag 
indicating when the thread is done. This could be added quite easily by 
adding a scope(exit) to the executed function (exec). It would not 
happen if the thread is terminated abnormally, but any thrown exception 
should trigger the flag. I'll note that the MessageBox class has a 
close() method that seems like it could be called.


Anyone want to make a PR? And no, I'm not going to :)

-Steve

Re: Detecting premature end of spawned threads with std.concurrency

[Matt Kline via Digitalmars-d-learn]

On Friday, 4 September 2015 at 08:33:08 UTC, Marc Schütz wrote:

They're called `OwnerTerminated` and `OwnerFailed` with an "r".


No, that's received by the child if the owning thread exits. I'm 
talking about the "parent" thread attempting to send to a child 
thread that has exited.


Relevant passage in TDPL: 
https://books.google.com/books?id=bn7GNq6fiIUC=PT602