Re: LDC+Dub+Vibe.d work on SmartOS 64bit now

[Alexandr Basko via Digitalmars-d-announce]

On Friday, 10 June 2016 at 22:20:20 UTC, Oleg Nykytenko wrote:

On Friday, 10 June 2016 at 21:40:22 UTC, flamencofantasy wrote:

ld: fatal: library -levent: not found



I think need install libevent.

In howto on 
https://wiki.dlang.org/LDC%2BDub%2BVibe.d_on_SmartOS_64bit.

I think misprint in line:
# pkgin in binutils gmake cmake scmgit python35 autoconf gcc49 
gcc49-libs unzip libconfig livevent


change "livevent" -> "libevent".


Sorry this is my misprint. I already corrected howto

Re: Accessing COM Objects

[Mike Parker via Digitalmars-d-learn]

On Monday, 13 June 2016 at 04:52:49 UTC, Mike Parker wrote:

On Monday, 13 June 2016 at 02:08:22 UTC, Incognito wrote:

What interface are you talking about? How can I cast to 
something I don't have? I do not have a photoshop COM 
interface. Are you saying that if CoCreateInstance worked that 
I can then use the iid or pUnk to access the COM? Do I get the 
members by trial and error? pUnk.width? Even if 
CoCreateInstance passed, what do I do next?


You have to define the interface yourself, extending from 
IUnknown, implementing whatever functions are available on the 
COM interface you want. Here's an example for the ID3D11Device 
interface:


https://github.com/auroragraphics/directx/blob/master/d3d11.d#L1332


Sorry. Hit send too soon.

Once you've got your interface defined, you should be able to do 
this:


MyCOMType mct;
auto hr = CoCreateInstance(_DOMDocument60, null, 
CLSCTX_ALL, , (void*)mct);


It's been a long time since I worked directly with COM, so there 
are probably details I'm missing, but this is the general idea.

Re: Accessing COM Objects

[Mike Parker via Digitalmars-d-learn]

On Monday, 13 June 2016 at 02:08:22 UTC, Incognito wrote:

What interface are you talking about? How can I cast to 
something I don't have? I do not have a photoshop COM 
interface. Are you saying that if CoCreateInstance worked that 
I can then use the iid or pUnk to access the COM? Do I get the 
members by trial and error? pUnk.width? Even if 
CoCreateInstance passed, what do I do next?


You have to define the interface yourself, extending from 
IUnknown, implementing whatever functions are available on the 
COM interface you want. Here's an example for the ID3D11Device 
interface:


https://github.com/auroragraphics/directx/blob/master/d3d11.d#L1332

Re: Fibers, what for?

[Ali Çehreli via Digitalmars-d-learn]

On 06/12/2016 07:19 PM, Patric Dexheimer wrote:

On Monday, 13 June 2016 at 00:57:11 UTC, Alex Parrill wrote:

Also note that Vibe.d, the largest fiber-based framework D has to
offer, is capable of running several coroutines in parallel on
multiple threads, meaning you must use the same level of
synchronization as if you were using threads.


Vibe.d framework share the same fibers between threads?
Or each thread have his own fibers?
I was trying this(shared fibers) but it didnt work.


D fibers don't (actually, can't) move between threads. Vibe.d uses 
regular D fibers, so it's true there as well.


The main reason why it's not currently possible is data being 
thread-local by default. If fibers could move, a fiber accessing a 
thread-local data would continue accessing the same data at the same 
address but it would be different data on that thread.


This huge thread has interesting discussions on not moving fibers 
between threads:


  http://forum.dlang.org/post/mf3hk7$1ucr$1...@digitalmars.com

Ali

Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?

[Asterism via Digitalmars-d]

On Friday, 10 June 2016 at 15:04:52 UTC, Ali Çehreli wrote:

On 06/10/2016 07:41 AM, Seb wrote:
>>   [...]
want to
> [...]
translating it
> [...]
in.
> [...]

[...]


IMHO maybe D编程 or D语言编程 is better than 编程在D, because 编程在D looks 
odd in Chinese.


Programming in Scala translated into Scala编程 in Chinese; 
Programming In Lua translated into Lua程序设计; Programming in C(3rd 
Edition) translated into C语言编程 and 4th Edition translated into 
C语言程序设计;


If this Chinese book is not published in Chinese, the original 
name "Programming in D" or "Programming in D 中文版" (Programming in 
D Chinese version) is also OK.

Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?

[Meta via Digitalmars-d]

On Monday, 13 June 2016 at 02:34:13 UTC, Dsby wrote:

On Friday, 10 June 2016 at 20:24:47 UTC, Meta wrote:

On Friday, 10 June 2016 at 14:26:31 UTC, FrankLike wrote:

Hi,everyone:
  The 'Programming In D' is a good book for new D coders,we 
want to start it in Chinese, do you have any good suggestions?


Thank you.


太好了！很不幸，我的中文知识不足够的，所以不可能帮你们。加油，我很兴奋的！


   这句中文说的很不错的。


你太客气了~

Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?

[Dsby via Digitalmars-d]

On Friday, 10 June 2016 at 20:24:47 UTC, Meta wrote:

On Friday, 10 June 2016 at 14:26:31 UTC, FrankLike wrote:

Hi,everyone:
  The 'Programming In D' is a good book for new D coders,we 
want to start it in Chinese, do you have any good suggestions?


Thank you.


太好了！很不幸，我的中文知识不足够的，所以不可能帮你们。加油，我很兴奋的！


   这句中文说的很不错的。

[Issue 11047] UDA + getAttributes bypass purity/safety check

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/5863

--

Re: Constraining template with function signature

[Carl Vogel via Digitalmars-d-learn]

On Thursday, 9 June 2016 at 19:08:52 UTC, cy wrote:
But it's probably clearer to use that is(typeof({ how this 
function will be called })) trick.


A very delayed thanks to both of you. It does seem like it would 
be useful to have something like a hasSignature!(Fun, Ret, 
Args...) defined in std.traits. But Steven's solution is pretty 
good.


Thanks again!

Re: Fibers, what for?

[Patric Dexheimer via Digitalmars-d-learn]

On Monday, 13 June 2016 at 00:57:11 UTC, Alex Parrill wrote:
Also note that Vibe.d, the largest fiber-based framework D has 
to offer, is capable of running several coroutines in parallel 
on multiple threads, meaning you must use the same level of 
synchronization as if you were using threads.


Vibe.d framework share the same fibers between threads?
Or each thread have his own fibers?
I was trying this(shared fibers) but it didnt work.

Re: Accessing COM Objects

[Incognito via Digitalmars-d-learn]

On Monday, 13 June 2016 at 01:52:12 UTC, Mike Parker wrote:

On Monday, 13 June 2016 at 01:22:33 UTC, Incognito wrote:

I can do this stuff in C# by simply dragging and dropping a 
dll into the references and it works fine but is a bit slow. I 
was hoping I could speed things up using D but it seems like 
COM isn't really supported, despite what several references 
say.


Com *is* supported in D. I think it's better to work with 
interfaces rather than classes like the Wiki example:


interface MyCOMType : IUknown {}

Then when you get a pointer from CoCreateInstance or whatever, 
you cast it to the interface type and away you go.


In your code, your problem is that CoCreateInstance is failing, 
not that D doesn't support COM. It will help you to find out 
what the actual value of 'hr' is. Possible values are listed at 
[1].


[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686615(v=vs.85).aspx


What interface are you talking about? How can I cast to something 
I don't have? I do not have a photoshop COM interface. Are you 
saying that if CoCreateInstance worked that I can then use the 
iid or pUnk to access the COM? Do I get the members by trial and 
error? pUnk.width? Even if CoCreateInstance passed, what do I do 
next?

[Issue 11047] UDA + getAttributes bypass purity/safety check

[via Digitalmars-d-bugs]

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

--- Comment #1 from Walter Bright  ---
http://dlang.org/spec/attribute.html#UserDefinedAttribute

They are defined as "compile time expressions" meaning they have to be
evaluatable at compile time into a manifest constant. The bug here is this is
not being checked.

--

Re: Accessing COM Objects

[Mike Parker via Digitalmars-d-learn]

On Monday, 13 June 2016 at 01:22:33 UTC, Incognito wrote:

I can do this stuff in C# by simply dragging and dropping a dll 
into the references and it works fine but is a bit slow. I was 
hoping I could speed things up using D but it seems like COM 
isn't really supported, despite what several references say.


Com *is* supported in D. I think it's better to work with 
interfaces rather than classes like the Wiki example:


interface MyCOMType : IUknown {}

Then when you get a pointer from CoCreateInstance or whatever, 
you cast it to the interface type and away you go.


In your code, your problem is that CoCreateInstance is failing, 
not that D doesn't support COM. It will help you to find out what 
the actual value of 'hr' is. Possible values are listed at [1].


[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686615(v=vs.85).aspx

[Issue 13442] __gshared default value allowed in @safe function signature

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=11047

--

[Issue 11047] UDA + getAttributes bypass purity/safety check

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13442

--

Re: Gotchas for returning values from blocks

[Mike Parker via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 18:24:58 UTC, jmh530 wrote:

garbage collected variable and assign it to it. Everything 
seems to work fine. I'm just not sure if there are any gotchas 
to be aware of.


class Foo
{
int baz = 2;
}

void main()
{
import std.stdio : writeln;

Foo foo;
{
Foo bar = new Foo();
foo = bar;
}
//bar is now out of scope
assert(foo.baz == 2);
}


Everything works fine in your example because 'new' always 
allocates on the heap. Anything allocated on the stack is not 
guaranteed to be valid after the scope exits:


struct Foo
{
int baz;
~this() { baz = 1; }
}

void main()
{
import std.stdio : writeln;

Foo* foo;
{
Foo bar = Foo(10);
foo = 
}
//bar is now out of scope
assert(foo.baz == 10);
}

Struct constructors are always run when exiting a scope. More 
importantly, the pointer to bar is only valid until the stack 
address where it lives is overwritten by another stack 
allocation. In this example, there's no chance for that to happen 
before I access it, but it could happen at any time.

[Issue 13983] RefCounted needs to be pure, @safe, nothrow

[via Digitalmars-d-bugs]

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

--- Comment #4 from Walter Bright  ---
(In reply to Jack Stouffer from comment #2)
> Adding nothrow is also impossible because this throws
> when the computer is out of memory.

This is incorrect since the out-of-memory is an Error, not an Exception, and
nothrow functions can throw Errors.

--

Accessing COM Objects

[Incognito via Digitalmars-d-learn]

I've been reading over D's com and can't find anything useful. It 
seems there are different ways:


http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

which is of no help and requires an idl file, which I don't have.

Then theres this

http://wiki.dlang.org/COM_Programming

which is also of no help:

import std.stdio;

import std.stdio, core.sys.windows.com, core.sys.windows.windows, 
std.exception, std.meta, std.traits;
import std.utf, core.stdc.stdlib, core.sys.windows.objidl, 
core.sys.windows.ole2;

pragma(lib, "ole32.lib");


GUID Guid(string str)()
{
static assert(str.length==36, "Guid string must be 36 chars 
long");
enum GUIDstring = "GUID(0x" ~ str[0..8] ~ ", 0x" ~ str[9..13] 
~ ", 0x" ~ str[14..18] ~
", [0x" ~ str[19..21] ~ ", 0x" ~ str[21..23] ~ ", 0x" ~ 
str[24..26] ~ ", 0x" ~ str[26..28]
~ ", 0x" ~ str[28..30] ~ ", 0x" ~ str[30..32] ~ ", 0x" ~ 
str[32..34] ~ ", 0x" ~ str[34..36] ~ "])";

return mixin(GUIDstring);
}

int main(string[] argv)
{

	// Adobe Photoshop App 9.0 CLSID 
{c09f153e-dff7-4eff-a570-af82c1a5a2a8}
	// Adobe Photoshop App 9.1 CLSID 
{6DECC242-87EF-11cf-86B4-44455354}


	auto CLSID_DOMDocument60 = 
Guid!("6DECC242-87EF-11cf-86B4-44455354");

auto iid = IID_IUnknown;

void* pUnk;
	auto hr = CoCreateInstance(_DOMDocument60, null, 
CLSCTX_ALL, , );

if (FAILED(hr))
throw new Exception("Error!");

writeln("Hello D-World!");
return 0;
}

Maybe my CLSID's are wrong. Got them from the registry. The 
exception triggers each time. Even if it worked, I wouldn't know 
how to use it.


I can do this stuff in C# by simply dragging and dropping a dll 
into the references and it works fine but is a bit slow. I was 
hoping I could speed things up using D but it seems like COM 
isn't really supported, despite what several references say.

[Issue 13054] pure nothrow @safe std.algorithm.schwartzSort

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords|safe|
   Hardware|x86 |All
 OS|Windows |All

--- Comment #2 from Walter Bright  ---
(In reply to Walter Bright from comment #1)
> Partial fix: https://github.com/dlang/phobos/pull/4415

Which was pulled, and the Schwartz is now @safe.

--

Re: Fibers, what for?

[Alex Parrill via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 08:38:03 UTC, chmike wrote:
Fibers don't need synchronization to access shared data. This 
removes the overhead of synchronization and simplifies 
"multitheaded" programming greatly.


This is misleading. Any sort of cooperative system needs 
synchronization when two or more tasks try to access the same 
data, whether those "tasks" are OS threads, fibers, different 
machines on a network, etc.


Fibers do make it easier, as no task can run in parallel with the 
current one and switching tasks is done explicitly via yield, 
effectively giving the current fiber exclusive access to the 
entire program state in between yields. But if you need to hold 
onto a resource across a yield, you will need the usual set of 
concurrency primitives, like locks.


(A practical example: making a commit using the Node.js libgit 
bindings involves several asynchronous steps, during which other 
tasks may access it. If you don't want anyone else messing with 
the Git repo while you are making a commit, you must protect the 
repo with a lock.)


Also note that Vibe.d, the largest fiber-based framework D has to 
offer, is capable of running several coroutines in parallel on 
multiple threads, meaning you must use the same level of 
synchronization as if you were using threads.

Re: Button: A fast, correct, and elegantly simple build system.

[Walter Bright via Digitalmars-d-announce]

On 5/30/2016 12:16 PM, Jason White wrote:

Here is an example build description for DMD:

https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua

I'd say that's a lot easier to read than this crusty thing:

https://github.com/dlang/dmd/blob/master/src/posix.mak


Yes, the syntax looks nice.

Re: dlang-requests 0.1.7 released

[ikod via Digitalmars-d-announce]

On Sunday, 12 June 2016 at 22:37:34 UTC, Alexander Milushev wrote:

On Saturday, 11 June 2016 at 23:03:52 UTC, ikod wrote:

Hello,

Dlang-requests is library created under influence of 
Python-requests, with primary goal of easy to use and 
performance.


It provide interfaces for HTTP(S) and FTP requests. You can 
tune request details, but for most cases you will need single 
and simple API call.


Latest release added streaming content from server and some 
performance improvements (avoiding some of unnecessary buffer 
copying).


Code and docs available at 
https://github.com/ikod/dlang-requests or as dub package.


Thanks Dlang authors and community for excellent language.


Hi, this is great project, but what about vibe.d compatibility?


This project doesn't depend on vibe.d, and I'm not sure if it can 
be directly used from inside vibe.d application, as it use 
blocked socket io.

Re: Button: A fast, correct, and elegantly simple build system.

[Jason White via Digitalmars-d-announce]

On Sunday, 12 June 2016 at 20:03:06 UTC, Walter Bright wrote:

On 6/3/2016 1:26 AM, Dicebot wrote:
From that perspective, the best build system you could 
possibly have would look

like this:

```
#!/usr/bin/rdmd

import std.build;

// define your build script as D code
```


Yeah, I have often thought that writing a self-contained D 
program to build D would work well. The full power of the 
language would be available, there'd be nothing new to learn, 
and all you'd need is an existing D compiler (which we already 
require to build).


The core functionality of Button could be split off into a 
library fairly easily and there would be no dependency on Lua. 
Using it might look something like this:


import button;

immutable Rule[] rules = [
{
inputs: [Resource("foo.c"), Resource("baz.h")],
task: Task([Command(["gcc", "-c", "foo.c", "-o", 
"foo.o"])]),

outputs: [Resource("foo.o")]
},
{
inputs: [Resource("bar.c"), Resource("baz.h")],
task: Task([Command(["gcc", "-c", "bar.c", "-o", 
"bar.o"])]),

outputs: [Resource("bar.o")]
},
{
inputs: [Resource("foo.o"), Resource("bar.o")],
task: Task([Command(["gcc", "foo.o", "bar.o", "-o", 
"foobar"])]),

outputs: [Resource("foobar")]
}
];

void main()
{
build(rules);
}

Of course, more abstractions would be added to make creating the 
list of rules less verbose.


However, I question the utility of even doing this in the first 
place. You miss out on the convenience of using the existing 
command line interface. And for what? Just so everything can be 
in D? Writing the same thing in Lua would be much prettier. I 
don't understand this dependency-phobia.

Re: An Alternative to Deimos' OpenSSL Bindings

[David Nadlinger via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 21:49:21 UTC, Vladimir Panteleev wrote:

On Sunday, 12 June 2016 at 19:12:37 UTC, Meta wrote:
I wanted to use OpenSSL from D but I noticed that the Deimos 
bindings are for version 1.0.0e, which according to 
OpenSSL.org is an out of date version. Are there any bindings 
for the latest version, or an alternative that I could use? I 
know I could use std.digest for SHA512, but I still need a 
secure random number generator.


What's the problem? According to the OpenSSL changelog, SHA-512 
was added in v0.9.8.


Just in case that isn't clear, what Vladimir is pointing out is 
that unless you need a feature from the new versions – or OpenSSL 
breaks binary compatibility, which is unlikely to happen anytime 
soon – the old headers will work just fine.


 — David

Re: dlang-requests 0.1.7 released

[Alexander Milushev via Digitalmars-d-announce]

On Saturday, 11 June 2016 at 23:03:52 UTC, ikod wrote:

Hello,

Dlang-requests is library created under influence of 
Python-requests, with primary goal of easy to use and 
performance.


It provide interfaces for HTTP(S) and FTP requests. You can 
tune request details, but for most cases you will need single 
and simple API call.


Latest release added streaming content from server and some 
performance improvements (avoiding some of unnecessary buffer 
copying).


Code and docs available at 
https://github.com/ikod/dlang-requests or as dub package.


Thanks Dlang authors and community for excellent language.


Hi, this is great project, but what about vibe.d compatibility?

Re: Creating a reference counted type?

[Gary Willoughby via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 15:05:53 UTC, ketmar wrote:
this is basically how refcounted structs are done. note that i 
just typed the code into reply box, so it may not compile or 
contain some small bugs, but i think you got the idea.


Thanks for the replies guys.

Re: An Alternative to Deimos' OpenSSL Bindings

[Vladimir Panteleev via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 19:12:37 UTC, Meta wrote:
I wanted to use OpenSSL from D but I noticed that the Deimos 
bindings are for version 1.0.0e, which according to OpenSSL.org 
is an out of date version. Are there any bindings for the 
latest version, or an alternative that I could use? I know I 
could use std.digest for SHA512, but I still need a secure 
random number generator.


What's the problem? According to the OpenSSL changelog, SHA-512 
was added in v0.9.8.

Re: An Alternative to Deimos' OpenSSL Bindings

[Peter Lewis via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 19:12:37 UTC, Meta wrote:
I wanted to use OpenSSL from D but I noticed that the Deimos 
bindings are for version 1.0.0e, which according to OpenSSL.org 
is an out of date version. Are there any bindings for the 
latest version, or an alternative that I could use? I know I 
could use std.digest for SHA512, but I still need a secure 
random number generator.


There is an alternative, if you search dub you can find this[1] 
library. It has been updated last in December 2016. Hope it works 
well for you!


1 https://code.dlang.org/packages/dcrypto

Re: I'd love to see DScript one day ...

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 12 June 2016 at 12:42:23 UTC, Adam D. Ruppe wrote:
The standard has moved on, the bar on performance has raised, 
and dmdscript hasn't even kept up with changes in D.


Not too worried about the performance, but EcmaScript 6 has 
increased the feature set so much that the spec is over twice as 
large as for EcmaScript 5... And Chrome 52 is apparently shipping 
with both ES6 and some ES7, so it will be hard to keep up.

Re: Button: A fast, correct, and elegantly simple build system.

[cym13 via Digitalmars-d-announce]

On Sunday, 12 June 2016 at 20:03:06 UTC, Walter Bright wrote:

On 6/3/2016 1:26 AM, Dicebot wrote:
From that perspective, the best build system you could 
possibly have would look

like this:

```
#!/usr/bin/rdmd

import std.build;

// define your build script as D code
```


Yeah, I have often thought that writing a self-contained D 
program to build D would work well. The full power of the 
language would be available, there'd be nothing new to learn, 
and all you'd need is an existing D compiler (which we already 
require to build).


What about Attila's work with reggae?

Re: Gotchas for returning values from blocks

[jmh530 via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 19:30:49 UTC, Era Scarecrow wrote:

On Sunday, 12 June 2016 at 18:24:58 UTC, jmh530 wrote:

I'm just not sure if there are any gotchas to be aware of.


 Aside from forgetting it's it's own block, you might add a 
return statement to it and leave the entire function. Or forget 
what's in what scope (assuming you do more than 1-2 pages of 
code per function). They do sorta behave like inlined void 
delegate functions (skip the call & heavy stack management).


 Unless there's a good reason for using blocks I don't see the 
need, since you will likely use inner scopes in if statements 
and the like anyways.


Good points. Thanks for the reply.

Re: Button: A fast, correct, and elegantly simple build system.

[Walter Bright via Digitalmars-d-announce]

On 6/3/2016 1:26 AM, Dicebot wrote:

From that perspective, the best build system you could possibly have would look
like this:

```
#!/usr/bin/rdmd

import std.build;

// define your build script as D code
```


Yeah, I have often thought that writing a self-contained D program to build D 
would work well. The full power of the language would be available, there'd be 
nothing new to learn, and all you'd need is an existing D compiler (which we 
already require to build).

Re: Monads in D

[Timon Gehr via Digitalmars-d]

On 12.06.2016 20:28, Max Samukha wrote:

On Sunday, 12 June 2016 at 16:46:13 UTC, Ola Fosheim Grøstad wrote:



Input world, output modified world... Geez, why doesn't tutorials on
Monads say that before they try to explain it with code?


Because IO is just one of many applications of the monad concept?


Most of the tutorials are not actually very good.

Re: The Problem With DIPs

[Walter Bright via Digitalmars-d]

On 6/10/2016 9:38 AM, Ola Fosheim Grøstad wrote:

On Friday, 10 June 2016 at 15:37:31 UTC, Steven Schveighoffer wrote:

DIP 20 by Alex Rønne Petersen in 2012


Alex is a member of Phobos, druntime, dlang.org, and tools team.


Aww, apologies to Alex :-)

Modifying the compiler might be more productive than writing a DIP, then.



Consider: would you ever have noticed a n.g. posting written by Alex in 2012?

Re: The Problem With DIPs

[Walter Bright via Digitalmars-d]

On 6/12/2016 11:50 AM, Dicebot wrote:

Your are very correct about importance of link stability though. What
comes to my mind immediately is to store all DIPs in same folder but
keep Approved/Implementec/etc as folders containing symlinks to the
merged one (git stores symlinks just fine).


I like Bugzilla's method of tagging issues, which allows arbitrary crosscuts to 
be made.

Re: Gotchas for returning values from blocks

[Era Scarecrow via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 18:24:58 UTC, jmh530 wrote:

I'm just not sure if there are any gotchas to be aware of.


 Aside from forgetting it's it's own block, you might add a 
return statement to it and leave the entire function. Or forget 
what's in what scope (assuming you do more than 1-2 pages of code 
per function). They do sorta behave like inlined void delegate 
functions (skip the call & heavy stack management).


 Unless there's a good reason for using blocks I don't see the 
need, since you will likely use inner scopes in if statements and 
the like anyways.

Re: The Problem With DIPs

[Dicebot via Digitalmars-d]

On 06/12/2016 09:58 PM, Vladimir Panteleev wrote:
> On Sunday, 12 June 2016 at 18:50:06 UTC, Dicebot wrote:
>> Your are very correct about importance of link stability though. What
>> comes to my mind immediately is to store all DIPs in same folder but
>> keep Approved/Implementec/etc as folders containing symlinks to the
>> merged one (git stores symlinks just fine).
> 
> This might not be the case on Windows.
> 
> Does GitHub present symlinks in a nice way (i.e. as a redirect)?

AFAIK in Windows those are visible as text files containing linked path.
Github doesn't seem to be very helpful either :
https://github.com/Dicebot/DIPs/blob/master/Drafts/DIP20.md :(

An Alternative to Deimos' OpenSSL Bindings

[Meta via Digitalmars-d-learn]

I wanted to use OpenSSL from D but I noticed that the Deimos 
bindings are for version 1.0.0e, which according to OpenSSL.org 
is an out of date version. Are there any bindings for the latest 
version, or an alternative that I could use? I know I could use 
std.digest for SHA512, but I still need a secure random number 
generator.

Re: The Problem With DIPs

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 12 June 2016 at 18:50:06 UTC, Dicebot wrote:
Your are very correct about importance of link stability 
though. What comes to my mind immediately is to store all DIPs 
in same folder but keep Approved/Implementec/etc as folders 
containing symlinks to the merged one (git stores symlinks just 
fine).


This might not be the case on Windows.

Does GitHub present symlinks in a nice way (i.e. as a redirect)?

Re: The Problem With DIPs

[Dicebot via Digitalmars-d]

On 06/12/2016 08:19 PM, Guillaume Boucher wrote:
> On Sunday, 12 June 2016 at 12:16:11 UTC, Dicebot wrote:
>> On 06/09/2016 01:12 AM, Walter Bright wrote:
>>> On 6/8/2016 1:47 PM, Dicebot wrote:
 I will finish description for proposed process this weekend and send
 it to
 dmd-internal mail list.
>>>
>>> Cool!
>>
>> http://forum.dlang.org/thread/d5996d6d-1f8e-2fa7-31a7-177c121a9...@dicebot.lv
>>
> 
> What are the reasons for putting the DIPs into several directories
> (Drafts, Approved, Implemented and Discarded)?  Rust also did that at
> first, but they merged them later into one folder (see
> https://github.com/rust-lang/rfcs/issues/360).  If you keep the
> structure as is, what is the preferred way to link to a certain DIP?

Rationale is to allow quickly navigate through existing DIPs (in absence
of actual database to query), filtering categories is probably most
common navigation task.

Your are very correct about importance of link stability though. What
comes to my mind immediately is to store all DIPs in same folder but
keep Approved/Implementec/etc as folders containing symlinks to the
merged one (git stores symlinks just fine).

Re: Monads in D

[Max Samukha via Digitalmars-d]

On Sunday, 12 June 2016 at 16:46:13 UTC, Ola Fosheim Grøstad 
wrote:




Input world, output modified world... Geez, why doesn't 
tutorials on Monads say that before they try to explain it with 
code?


Because IO is just one of many applications of the monad concept?

Gotchas for returning values from blocks

[jmh530 via Digitalmars-d-learn]

I was thinking about how Rust can return arbitrarily from blocks. 
It occurred to me recently that there's no reason you can't do 
that in D. I'm just not sure if there are any limitations. For 
instance, in the code below, I create an object but don't 
allocate anything, then in a block I create a garbage collected 
variable and assign it to it. Everything seems to work fine. I'm 
just not sure if there are any gotchas to be aware of.


class Foo
{
int baz = 2;
}

void main()
{
import std.stdio : writeln;

Foo foo;
{
Foo bar = new Foo();
foo = bar;
}
//bar is now out of scope
assert(foo.baz == 2);
}

Re: The Problem With DIPs

[Guillaume Boucher via Digitalmars-d]

On Sunday, 12 June 2016 at 12:16:11 UTC, Dicebot wrote:

On 06/09/2016 01:12 AM, Walter Bright wrote:

On 6/8/2016 1:47 PM, Dicebot wrote:
I will finish description for proposed process this weekend 
and send

it to
dmd-internal mail list.


Cool!


http://forum.dlang.org/thread/d5996d6d-1f8e-2fa7-31a7-177c121a9...@dicebot.lv


What are the reasons for putting the DIPs into several 
directories (Drafts, Approved, Implemented and Discarded)?  Rust 
also did that at first, but they merged them later into one 
folder (see https://github.com/rust-lang/rfcs/issues/360).  If 
you keep the structure as is, what is the preferred way to link 
to a certain DIP?

Re: Monads in D

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 12 June 2016 at 15:33:31 UTC, Timon Gehr wrote:
I don't see the point of this criticism. Different language 
makes sense to different people.


I think he had a point, but his explanation was harder to follow 
than this one:


http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf

Input world, output modified world... Geez, why doesn't tutorials 
on Monads say that before they try to explain it with code?

Re: Monads in D

[Timon Gehr via Digitalmars-d]

On 11.06.2016 20:27, deadalnix wrote:




Honestly, the whole bind/return is just a giant NIH. >>> and >>= are its
symptoms. There is a reason why nobody understands jack shit about monad
even after 10s of tutorial when they aren't even hard in any way:
because haskell and alike have made all that is in their power to
obfuscate what is a monad.

I could go on, but this guy already did it way better that I can:
https://www.infoq.com/presentations/functional-pros-cons

The part about monad starts 25mins in.


I don't see the point of this criticism. Different language makes sense 
to different people.

Re: Creating a reference counted type?

[ZombineDev via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 14:49:18 UTC, Gary Willoughby wrote:

On Sunday, 12 June 2016 at 14:45:12 UTC, ketmar wrote:
ahem... wut?! we have one copy of our struct freed half the 
way, and another copy has refcount of 2, so it won't be freed 
at all. it doesn't so innocent as it looks: we may try to use 
`f` in `main`... just to find out that resources was 
mysteriously freed, and refcount is total garbage.


Hmmm. I thought it looked *too* simple. Have you any idea if 
there is a simple solution to this?


You need to allocate the ref count on the heap so it is actually 
shared between all copies of the struct. Also if you want to 
share the reference between multiple threads, you need to use 
core.atomic.atomicOp for incrementing and decrementing.


See std.typecons.RefCounteed's implementation for reference 
https://github.com/dlang/phobos/blob/v2.071.0/std/typecons.d#L4712


You can use AffixAllocator 
http://dlang.org/phobos-prerelease/std_experimental_allocator_building_blocks_affix_allocator.html, so that ref count is automatically placed before or after the actual objected that is being ref counted. Just note that AffixAllocator is safe to use only by a single thread.

Re: Creating a reference counted type?

[ketmar via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 14:49:18 UTC, Gary Willoughby wrote:
Hmmm. I thought it looked *too* simple. Have you any idea if 
there is a simple solution to this?


yes. you have to turn your refcount to pointer. ;-)

the cause of "misbehave" is the fact that there can exist several 
copies of the struct made in different program points, and they 
all have *independent* refcounter. but all those copies should 
have the *same* refcounter. the easiest way to solve this is to 
allocate refcounter separately, and only share *pointer* to it, 
like this:


struct Foo {
  int* refcount;

  void allocResources () {
import core.stdc.stdlib : malloc;
assert(refcount is null);
refcount = cast(int*)malloc(int.size);
*refcount = 1;
// init other resources
  }

  this (this) { if (refcount !is null) *refcount += 1; }

  // we need to do this in opAssign() and in dtor, hence the 
function

  private void decRef () {
if (refcount !is null) {
  if ((*refcount -= 1) == 0) {
import core.stdc.stdlib : free;
free(refcount);
// free resources
  }
}
  }

  ~this (this) { decRef(); }

  // yes, we need this too
  void opAssign (Foo src) {
*src.refcount += 1; // it is important to increase it first, 
in case `src` and `this` are sharing refcount

decRef(); // release our resources
*refcount = *src.refcount;
// copy other handles and so on
  }
}


this is basically how refcounted structs are done. note that i 
just typed the code into reply box, so it may not compile or 
contain some small bugs, but i think you got the idea.

Re: Perl6 Unicode support

[Andrew Godfrey via Digitalmars-d-announce]

On Sunday, 12 June 2016 at 08:15:37 UTC, ag0aep6g wrote:

On 06/12/2016 05:16 AM, Andrew Godfrey wrote:
Eg it says ".chars returns the number of characters (aka 
graphemes)"


Does this count the number of graphemes, or the number of 
grapheme
clusters? Later on with \r\n it pretty much says that it 
counts grapheme

clusters. Here it says it counts graphemes.


Sorry, I still don't get it. Can you give an example string 
where counting graphemes gives a different result from counting 
grapheme clusters?


Huh. On researching "grapheme cluster", I see it is a weird 
Unicode term that apparently means the same thing as grapheme. 
Definitely something to avoid in an article (or, explain very 
carefully).
To the uninitiated, "grapheme cluster" means "a cluster of 
graphemes" and implies a one-to-many mapping.

Re: Creating a reference counted type?

[Gary Willoughby via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 14:45:12 UTC, ketmar wrote:
ahem... wut?! we have one copy of our struct freed half the 
way, and another copy has refcount of 2, so it won't be freed 
at all. it doesn't so innocent as it looks: we may try to use 
`f` in `main`... just to find out that resources was 
mysteriously freed, and refcount is total garbage.


Hmmm. I thought it looked *too* simple. Have you any idea if 
there is a simple solution to this?

Re: Creating a reference counted type?

[ketmar via Digitalmars-d-learn]

this won't work at all. let's insert `writeln("FREE!");` in dtor, 
and test it:


auto foo (Foo foo) {
  version(dump) writeln(foo._refCount);
  return foo;
}

void main () {
  auto f = foo(Foo());
  version(dump) writeln(f._refCount);
}

it prints "FREE" once, so it looks like the whole thing is 
working. but now let's try this with `-version=dump`:


1
FREE!
2

ahem... wut?! we have one copy of our struct freed half the way, 
and another copy has refcount of 2, so it won't be freed at all. 
it doesn't so innocent as it looks: we may try to use `f` in 
`main`... just to find out that resources was mysteriously freed, 
and refcount is total garbage.

[Issue 16166] struct constructor and AliasSeq

[via Digitalmars-d-bugs]

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

--- Comment #1 from Danila Letunovskiy  ---
this(T...)(T t){ this.tupleof[0..t.length] = t; }

I want that this work by default.

--

Re: Creating a reference counted type?

[Gary Willoughby via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 14:29:19 UTC, Gary Willoughby wrote:
Another thing that is puzzling me is that when creating an 
instance of the above struct and passing as an argument to a 
function, the copy constructor is called and the reference 
count is incremented. This is expected. However, when the 
function returns, the destructor is called (on the copy) and 
the reference count lowered. How does the original instance 
know of the updated reference count from the copy?


Actually, this doesn't puzzle me at all! I think I must be tired. 
Ignore this paragraph, it doesn't make sense. lol.

Creating a reference counted type?

[Gary Willoughby via Digitalmars-d-learn]

I'm wondering if it's this easy to create a reference counted 
type:


struct Foo
{
int _refCount = 1;

this(...)
{
// allocate resources, etc.
}

this(this)
{
this._refCount++;
}

~this()
{
this._refCount--;

if (this._refCount == 0)
{
// free resources.
}
}
}

Are there any other considerations I need to handle?

Another thing that is puzzling me is that when creating an 
instance of the above struct and passing as an argument to a 
function, the copy constructor is called and the reference count 
is incremented. This is expected. However, when the function 
returns, the destructor is called (on the copy) and the reference 
count lowered. How does the original instance know of the updated 
reference count from the copy?

Re: How to detect/filter modules in __traits(allMembers)?

[Random D user via Digitalmars-d-learn]

On Saturday, 11 June 2016 at 20:30:47 UTC, Basile B. wrote:

On Saturday, 11 June 2016 at 19:45:56 UTC, Random D user wrote:

Any good ideas how to do that?

I couldn't figure it out in a short amount of time, but I 
expect that it's possible. I'm probably missing something 
obvious here. Probably because D's reflection/meta programming 
facilities are a bit all over the place (and unnecessarily 
convoluted IMO).
Also I'm not super familiar with every compile-time feature, 
which is why I want to learn and some meta functions/templates 
myself.


[...]


It will compile if you define the option informational warnings 
(-wi).


Yes, ignoring deprecations gets me forward (basically the same as 
dropping back to previous compiler version), but I'd rather 
figure out/know a proper solution.


I suppose I could wrap those structs (with UDA) into a another 
named struct or empty template to split them into a separate 
"namespace" from the import modules.
I guess that wouldn't be as bad since all the structs are similar 
which means their names are similar. So basically, NameType would 
become Type.Name. Hmm...


Anyway, that workaround seems a bit silly, so I'm hoping to find 
a proper, generic and robust solution without any gimmicks.

Re: What's up with GDC?

[Joerg Joergonson via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 13:23:26 UTC, Adam D. Ruppe wrote:

On Sunday, 12 June 2016 at 13:05:48 UTC, Joerg Joergonson wrote:
BTW, when I compile a simple project with your simpledisplay 
it takes up around 300MB(for ldc, 400 for dmd) and uses about 
15% cpu.


What's your code? The library itself does fairly little so the 
time probably depends on your draw loop or timer settings 
(though it did have a memory leak until recently, it wasn't 
apparent until something had been running for a really long 
time - I use it in my day-to-day terminal emulator, so I have 
like 40 copies of the process running for months on end here...)



I'm leaving in 2 minutes for church btw so I might not answer 
you for about 5 hours when I'm back at the computer.


Well, it's about the same when I comment all my code out! It 
drops about 30 megs and a percent or two but still quite large.


When I remove all code, it is 2MB in size and 0 cpu(I just use 
Sleep to keep it from terminating).


When I try to use a sleep before the event loop to and just call 
create2dWindow, I get


Error: undefined identifier 'Sleep' in module 'core.thread', did 
you mean function 'Sleep'?		


Which godly in it's descriptive powers, right?

The code added is

import core.thread;
core.thread.Sleep(1);

which is the same code I use in main() which works(worked)

import core.thread : Sleep;
Sleep(1);

works though. Basically keeping the event loop uses around 12% 
cpu and 12MB of memory. Adding in my code, which simply uses your 
png to load some images and display them balloons it to 400MB. 
The exe is only 7MB in size.


So, I believe it is your code. The event loop is using quite a 
bit of cpu even when not "doing" anything(haven't look at it 
behind the scenes though).


The memory is probably from loading the images, possibly doubling 
all the images to powers of 2 might explain some of the bloat. I 
have a few large images that when uncompressed might be 20-40MB 
total and several smaller ones, probably insignificant. Shouldn't 
add up to 300MB though.


Once I get further in I'll try to see whats going on. I haven't 
noticed it leaking memory though.


Do you know if there is a way to get the largest used memory 
chunks and what is using them? That might tell the story!

.stringof

[Timon Gehr via Digitalmars-d]

On 12.06.2016 15:52, Timon Gehr wrote:

You may very well be right that it would be more consistent to return
the name of the alias, but I think what .stringof returns is an
independent concern. (Last time I checked, it was completely unspecified
anyway btw.)


What do you think about the following?

enum e=3;
static assert(e.stringof=="3");

Re: Passing private functions to template algorithms

[Timon Gehr via Digitalmars-d]

On 12.06.2016 15:52, Timon Gehr wrote:

semantics are useful


is useful

Re: Passing private functions to template algorithms

[Timon Gehr via Digitalmars-d]

On 12.06.2016 13:05, Dicebot wrote:

On 06/12/2016 01:55 PM, Timon Gehr wrote:

On 12.06.2016 10:28, Dicebot wrote:

On 06/07/2016 09:59 PM, Timon Gehr wrote:

I think it is obvious that this should work. Visibility checks need to
happen during identifier lookup. This lookup is happening in the module
where isFileNothrow is visible.


My understanding is that right now template alias argument means
transparent symbol lookup. It acts as if doesn't access alias symbol in
template but aliased one directly.
...


The lookup accesses the alias and is immediately rewritten to refer to
the aliased symbol. Visibility checks should be applied during the
lookup, but not after the rewrite.


Yes, that is natural solution but it makes alias itself first-class
symbol which leads to my example snippet question.
...


In my mind it already is a first-class symbol (it can even be part of an 
overload set), but after you look it up, it is immediately rewritten to 
another symbol.


https://github.com/tgehr/d-compiler/blob/master/semantic.d#L4670

Does DMD special-case it during lookup instead?


I agree such semantics are sub-optimal but changing that can break quite
some existing idioms. Consider this snippet for example:

enum name ( alias sym ) = sym.stringof;

Right now it evaluates to name of passed symbol.  If we change lookup
semantics to be non-transparent, it must always return `sym` for
consistency.



I completely disagree that this would need to happen. E.g.
fullyQualifiedName should work with private symbols just as well as with
public ones.

Maybe this is helpful: https://en.wikipedia.org/wiki/Information_hiding


Private or public is irrelevant here, it seems you have misunderstood my
concern.


Probably I indeed misunderstood your concern, but what I disagree with 
is the notion that breaking code not directly checking for visibility is 
somehow a prerequisite for having the correct visibility checks in 
place. You may very well be right that it would be more consistent to 
return the name of the alias, but I think what .stringof returns is an 
independent concern. (Last time I checked, it was completely unspecified 
anyway btw.)



The essential question is "what the alias is?", not how it is
accessed. There must be no special cases for aliases regarding
private/public symbol access,


There are no special cases in what I propose. The alias rewrite has 
nothing to do with lookup:


https://github.com/tgehr/d-compiler/blob/master/scope_.d#L185

I guess this is precisely your proposal too?


it is matter of defining actual alias
semantics so that generic access rules start being useful.



I agree. (Or maybe rather, it is a matter of defining both such that the 
resulting semantics are useful, I don't know precisely where DMD goes 
astray here.)

Re: Passing private functions to template algorithms

[Artur Skawina via Digitalmars-d]

The language does not prevent taking the address of a private
symbol and escaping it.
The alias case isn't (ie shouldn't be) different.

artur

[Issue 16167] New: chm-nav.json generation is broken

[via Digitalmars-d-bugs]

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

  Issue ID: 16167
   Summary: chm-nav.json generation is broken
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: thecybersha...@gmail.com
  Reporter: c...@dawg.eu

The nightlies don't build since 2016-06-10 b/c chmgen fails to parse
chm-nav.json.
http://nightlies.dlang.org/dmd-2016-06-11/build.html

Can we somehow include a test in the dlang.org tester, that chm-nav.json is
valid json?

---
Loading navigation

std.json.JSONException@std\json.d(1336): Unexpected character '<'. (Line 1:240)

0x00430C12 in pure @safe void
std.json.parseJSON!(immutable(char)[]).parseJSON(immutable(char)[], int,
std.json.JSONOptions).error(immutable(char)[]) at
C:\Users\vagrant\clones\dmd\src\..\..\phobos\std\json.d(729)
...
0x00430BD6 in @safe std.json.JSONValue
std.json.parseJSON!(immutable(char)[]).parseJSON(immutable(char)[], int,
std.json.JSONOptions) at
C:\Users\vagrant\clones\dmd\src\..\..\phobos\std\json.d(1032)
0x00403476 in void chmgen.loadNavigation() at
C:\Users\vagrant\clones\dlang.org\chmgen.d(204)
0x004032C2 in _Dmain at C:\Users\vagrant\clones\dlang.org\chmgen.d(170)
---

--

Re: What's up with GDC?

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

On Sunday, 12 June 2016 at 13:05:48 UTC, Joerg Joergonson wrote:
BTW, when I compile a simple project with your simpledisplay it 
takes up around 300MB(for ldc, 400 for dmd) and uses about 15% 
cpu.


What's your code? The library itself does fairly little so the 
time probably depends on your draw loop or timer settings (though 
it did have a memory leak until recently, it wasn't apparent 
until something had been running for a really long time - I use 
it in my day-to-day terminal emulator, so I have like 40 copies 
of the process running for months on end here...)



I'm leaving in 2 minutes for church btw so I might not answer you 
for about 5 hours when I'm back at the computer.

Re: What's up with GDC?

[Joerg Joergonson via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 09:11:09 UTC, Johan Engelen wrote:

On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:


Here are the versions

The one that isn't working:
LDC - the LLVM D compiler (30b1ed):
  based on DMD v2.071.1 and LLVM 3.9.0git-d06ea8a
  built with LDC - the LLVM D compiler (1.0.0)
  Default target: x86_64-pc-windows-msvc
  Host CPU: skylake
  http://dlang.org - http://wiki.dlang.org/LDC

The one that is:
B:\DLang\ldc2\bin>ldc2 -version
LDC - the LLVM D compiler (1.0.0):
  based on DMD v2.070.2 and LLVM 3.9.0git
  built with LDC - the LLVM D compiler (1.0.0)
  Default target: i686-pc-windows-msvc
  Host CPU: skylake
  http://dlang.org - http://wiki.dlang.org/LDC


The first one is a pre-alpha (!) version.
The second one is our latest released version, which is the one 
I recommend you to use.


If you want your bugs to be noted and fixed, you should try 
that test version and report bugs. That's kind of what you are 
doing now, so thanks ;)  Of course, clarity in reporting is 
important to get bugs fixed...


Ok. Well, I didn't know I was using an alpha version. Two bugs I 
have:


1. Paths(imports to subdirs as explained in my other posts) are 
not correct. It seems to be dropping the last '\'. Probably a 
simple substring range bug. (e.g., 1..$-2 instead of 1..$-1). 
Since it works in the previous version, it shouldn't be too hard 
to diff on the modules path resolution code.


2. There seems to be an issue with the x86 libs not being 
correctly resolved. The default is to choose x64. When I compile 
for x86 it still uses them. Maybe a compiler switch is needed, 
but regardless this isn't good practice. -m32 is being passed, 
maybe this should select the 32-bit configuration?


If these are regressions then someone needs to be fired!!! If 
not, someone still needs to be fired! Or at least be forced to 
buy me a ham burger or something!

Re: What's up with GDC?

[Joerg Joergonson via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 12:38:25 UTC, Adam D. Ruppe wrote:

On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:

2. I got an error that I don't get with dmd:

Error: incompatible types for ((ScreenPainter) !is (null)): 
cannot use '!is' with types		


and I have defined ScreenPainter in my code. It is also in 
arsd's simpledisplay. I do not import simpledisplay directly:


It's probably the difference of the recent import rules bug 
fix. gamehelpers public imports simpledisplay, so its 
ScreenPainter will be visible there too.


You can probably just exclude it from the import by doing 
selective:


import arsd.gamehelpers : create2dWindow;

and comma list anything else you use from there (probably just 
OpenGlTexture, it is a small module).



But yeah, weird that it is different, but this was REALLY 
recently changed so if the release differs by just one month in 
version it could account for the difference.


Although, If I set the subsystem to windows I then get the 
error


There's another MSFT library needed there passing 
`-L/entry:mainCRTStartup` to the build should do it.


dmd 32 bit has its own library so it isn't needed there, but 
dmd 64 bit and ldc both I believe need the entry point.



Thanks. It worked! BTW, when I compile a simple project with your 
simpledisplay it takes up around 300MB(for ldc, 400 for dmd) and 
uses about 15% cpu. Basically just a modified example that draws 
some images which maybe take up 20MB total. Any ideas why it's 
taking up so much space and cpu? What's it doing on your machine?

Re: What's up with GDC?

[Joerg Joergonson via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 05:08:12 UTC, Mike Parker wrote:

On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:



1. I had an older distro(I think) of ldc. The ldc2.exe is 18MB 
while the "new" one is 36MB. I copied the old ldc bin dir to 
the new one and didn't change anything and everything compiled 
EXCEPT


That's just asking for problems. You may get lucky and find 
that it works, but in general you don't want to go around 
swapping compiler executables like that.





2. I got an error that I don't get with dmd:

Error: incompatible types for ((ScreenPainter) !is (null)): 
cannot use '!is' with types		


and I have defined ScreenPainter in my code. It is also in 
arsd's simpledisplay. I do not import simpledisplay directly:


The code is

import arsd.gamehelpers;
	auto window = create2dWindow(cast(int)width, cast(int)height, 
cast(int)ViewportWidth, cast(int)ViewportHeight, title);


// Let the gui handle painting the screen
window.redrawOpenGlScene = {
if (ScreenPainter !is null || !ScreenPainter()) <--- error
...
};

I have defined ScreenPainter elsewhere in the module.


So ScreenPainter is a *type* and not an instance of a type? 
That *should* be an error, no matter which compiler you use. 
You can't compare a type against null. What does that even 
mean? And if SimpleDisplay already defines the type, why have 
you redefined it?


Assuming ScreenPainter is a class, then:

if(ScreenPainter !is null) <-- Invalid

auto sp = new ScreenPainter;
if(sp !is null) <-- valid




I can fix this by avoiding the import... but the point is that 
it's different than dmd.


If ScreenPainter is defined as a type, it shouldn't ever 
compile. How have you defined it?




So ldc parses things differently than dmd... I imagine this is 
a bug!


LDC and DMD share the same front end, meaning they parse code 
the same. I really would like to see your code, particularly 
your definition of ScreenPainter.


Although, If I set the subsystem to windows I then get the 
error


 error LNK2019: unresolved external symbol WinMain referenced 
in function "int __cdecl __scrt_common_main_seh(void)" 
(?__scrt_common_main_seh@@YAHXZ)>

Which looks like it's not linking to runtime and/or phobos?


No, this has nothing to do with DRuntime, Phobos, or even D. 
It's a Windows thing. By default, when you compile a D program, 
you are creating a console system executable so your primary 
entry point is an extern(C) main function that is generated by 
the compiler. This initializes DRuntime, which in turn calls 
your D main function.


When using OPTLINK with DMD, the linker will ensure that the 
generated extern(C) main remains the entry point when you set 
the subsystem to Windows. When using the MS linker, this is not 
the case. The linker will expect WinMain to be the entry point 
when the subsystem is set to Windows. If you do not have a 
WinMain, you will see the error above. In order to keep the 
extern(C) main as your entry point, you have to pass the /ENTRY 
option to the linker (see[1]). LDC should provide a means for 
passing linker options. You can probably set in VisualD's 
project settings, but if there's no field for it then ldc2 
--help may tell you what you need.


Alternatively, you can create a WinMain, but then you need to 
initialize DRuntime yourself. See [2], but ignore the .def file 
requirement since you are already setting the subsystem.





I seriously don't know how anyone gets anything done with all 
these problems ;/ The D community can't expect to get people 
interested in things don't work. If it wasn't because the D 
language was so awesome I wouldn't stick around! It's as if no 
one does any real testing on this stuff before it's released ;/


Then I would ask you to stop and think. There are a number of 
people using D without problems every day, including several 
companies. Obviously, they aren't having the same difficulties 
you are, else they wouldn't be successfully using D. You seem 
to be very quick to blame the tools rather than considering you 
might not fully understand how to use them. I don't mean that 
in a disparaging way. I've been there myself, trying to get 
something I wanted to use working and failing, then getting 
frustrated and blaming the tools. These days, I always blame 
yourself first. Sure, the tools sometimes have bugs and other 
issues, but more often than not it's because I'm using them the 
wrong way.


Right now, documentation on getting up to speed with LDC is 
sorely lacking. That's a valid criticism to make. For people 
who aren't familiar with it, or who aren't well versed in 
working with ahead of time compilers, whichever the case may 
be, it may not be the best choice for getting started with D. 
Since you seem to be having difficulties using LDC and since 
you've already told me that DMD is working for you, I strongly 
recommend that you use DMD instead for now. Once you are 

Re: I'd love to see DScript one day ...

[Adam D. Ruppe via Digitalmars-d]

On Sunday, 12 June 2016 at 12:05:49 UTC, Ola Fosheim Grøstad 
wrote:

Conformance would be more important so that you can
use libraries and compilers that compile to EcmaScript.


That's kinda the problem with dmdscript: it is an excellent and 
conformant implementation of Javascript that performed better 
than its competitors... many years ago.


The standard has moved on, the bar on performance has raised, and 
dmdscript hasn't even kept up with changes in D.


It's still a very good implementation of ECMAScript 3, and with a 
bit of D stuff, interfacing with it is reasonably easy, but tbh 
it just isn't something I'd use anymore... my script.d is easier 
to build and interface for quick toys, and one of the newer JS 
engines is better at Javascript itself.

Re: What's up with GDC?

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

On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:

2. I got an error that I don't get with dmd:

Error: incompatible types for ((ScreenPainter) !is (null)): 
cannot use '!is' with types		


and I have defined ScreenPainter in my code. It is also in 
arsd's simpledisplay. I do not import simpledisplay directly:


It's probably the difference of the recent import rules bug fix. 
gamehelpers public imports simpledisplay, so its ScreenPainter 
will be visible there too.


You can probably just exclude it from the import by doing 
selective:


import arsd.gamehelpers : create2dWindow;

and comma list anything else you use from there (probably just 
OpenGlTexture, it is a small module).



But yeah, weird that it is different, but this was REALLY 
recently changed so if the release differs by just one month in 
version it could account for the difference.



Although, If I set the subsystem to windows I then get the error


There's another MSFT library needed there passing 
`-L/entry:mainCRTStartup` to the build should do it.


dmd 32 bit has its own library so it isn't needed there, but dmd 
64 bit and ldc both I believe need the entry point.

Re: I'd love to see DScript one day ...

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 12 June 2016 at 12:30:46 UTC, ketmar wrote:
js is fubared from the start. there is no need to follow the 
broken path.


Whatever, the core of JavaScript is close to Self:

https://en.wikipedia.org/wiki/Self_(programming_language)

JavaScript was just messy in the details. ES6 is fixing a lot of 
that.

Re: I'd love to see DScript one day ...

[ketmar via Digitalmars-d]

On Sunday, 12 June 2016 at 12:25:00 UTC, Ola Fosheim Grøstad 
wrote:

Well, ES6 is actually reasonably ok.


js is fubared from the start. there is no need to follow the 
broken path.

Re: I'd love to see DScript one day ...

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 12 June 2016 at 12:13:45 UTC, Chris wrote:

On Sunday, 12 June 2016 at 11:58:08 UTC, ketmar wrote:

On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote:
I haven't had a chance to look at the source code in detail 
yet. How hard would it be to integrate JIT and D (and C) 
interop?


not hard. there is extension example (extending engine with 
D). also, the engine compiles scripts to IR code, which can be 
JITed as is, or used as a base for some other code 
representation.


the worst thing (for me) is that it is javascript.


Yeah, same here! It'd be best to write a proper scripting 
language based on DMDScript.


Well, ES6 is actually reasonably ok. It has both generators and 
WeakSet (set of objects that is pruned if the object is collected 
and many many other improvements:


http://es6-features.org/

Re: D grammar

[ketmar via Digitalmars-d]

On Sunday, 12 June 2016 at 12:14:33 UTC, WebFreak001 wrote:
There is a full grammar definition on the D Spec pdf file: 
https://dlang.org/dlangspec.pdf


it is invalid. anyone who will try to write a parser following 
this grammar only will hit a wall.

Re: The Problem With DIPs

[Dicebot via Digitalmars-d]

On 06/09/2016 01:12 AM, Walter Bright wrote:
> On 6/8/2016 1:47 PM, Dicebot wrote:
>> I will finish description for proposed process this weekend and send
>> it to
>> dmd-internal mail list.
> 
> Cool!

http://forum.dlang.org/thread/d5996d6d-1f8e-2fa7-31a7-177c121a9...@dicebot.lv

Re: D grammar

[WebFreak001 via Digitalmars-d]

On Sunday, 12 June 2016 at 06:45:58 UTC, Russel Winder wrote:

I should know this, but…

Is there an official D grammar (EBNF or otherwise) or is the 
language

defined by the DMD parser?

I am looking to continue Kingsley's DLanguage IntelliJ IDEA 
plugin and for that it is necessary to have a grammar 
specification. Kingsley has been working on one, but there may 
be differences between it and 2.071. Given the compilers and 
all the supporting tools either there is one language 
specification they all work with or there is a lot of 
fragmented viewpoints as to what D actually is. I am hoping the 
latter is not the case.


There is a full grammar definition on the D Spec pdf file: 
https://dlang.org/dlangspec.pdf


I also converted the whole grammar (excluding Allocator & 
Deallocator Arguments) with some nicer names to a txt file: 
https://i.webfreak.org/c5aCpv

Re: I'd love to see DScript one day ...

[Chris via Digitalmars-d]

On Sunday, 12 June 2016 at 11:58:08 UTC, ketmar wrote:

On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote:
I haven't had a chance to look at the source code in detail 
yet. How hard would it be to integrate JIT and D (and C) 
interop?


not hard. there is extension example (extending engine with D). 
also, the engine compiles scripts to IR code, which can be 
JITed as is, or used as a base for some other code 
representation.


the worst thing (for me) is that it is javascript.


Yeah, same here! It'd be best to write a proper scripting 
language based on DMDScript.

Re: I'd love to see DScript one day ...

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote:
I haven't had a chance to look at the source code in detail 
yet. How hard would it be to integrate JIT and D (and C) 
interop? Theoretically something like the Derelict-D libs allow 
for interop with Python and Lua too. I think we could create 
something really nice and useful here.


I don't think JIT is needed to be useful. Conformance would be 
more important so that you can use libraries and compilers that 
compile to EcmaScript. But conformance to EcmasScript 6 is a big 
big big big job.


http://www.ecma-international.org/ecma-262/6.0/

Re: Interest in Paris area D meetups?

[Claude via Digitalmars-d]

On Thursday, 9 June 2016 at 17:35:32 UTC, Guillaume Chatelet 
wrote:

On Thursday, 9 June 2016 at 16:27:41 UTC, Claude wrote:
On Thursday, 9 June 2016 at 09:11:05 UTC, Guillaume Chatelet 
wrote:

Sounds good to me.
How about next Wednesday (15th) at "Bière et Malt" (4 rue 
Poissonnière

in the 2nd district) at say 19:00?


Ok, great!


FYI my email address: chatelet.guillaume at gmail


Fine, did you receive my email?

[Issue 16149] foreach_reverse can't handle index variable of type int

[via Digitalmars-d-bugs]

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

--- Comment #6 from Ketmar Dark  ---
(In reply to Steven Schveighoffer from comment #5)
> int x = a.length would continue to be invalid (on 64-bit CPU). It's just for
> foreach_reverse.

then i'll inevitably ask why `int x = a.length;` is invalid, but
`foreach_reverse (int x, v; a)` is valid. that `foreach` obviously does the
assign under the hood (at least this is the most practical way to imagine it).

the only way to skip that "hidden assign" is to redefive `foreach_reverse`
completely — by still using increasing index in it, so x will go from 0 upto
limit. otherwise you just introducing a random pseudo-solution by randomly
breaking the rules.

--

Re: I'd love to see DScript one day ...

[ketmar via Digitalmars-d]

On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote:
I haven't had a chance to look at the source code in detail 
yet. How hard would it be to integrate JIT and D (and C) 
interop?


not hard. there is extension example (extending engine with D). 
also, the engine compiles scripts to IR code, which can be JITed 
as is, or used as a base for some other code representation.


the worst thing (for me) is that it is javascript.

[Issue 16149] foreach_reverse can't handle index variable of type int

[via Digitalmars-d-bugs]

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

--- Comment #5 from Steven Schveighoffer  ---
int x = a.length would continue to be invalid (on 64-bit CPU). It's just for
foreach_reverse.

What feels wrong is the OP's code that I can foreach some array in a certain
way, but not foreach reverse the identical thing.

My point was that foreach_reverse with a smaller index is valid for all cases
that foreach with a smaller index is valid. But foreach we allow and
foreach_reverse we disallow. Seems arbitrary.

--

Re: I'd love to see DScript one day ...

[Chris via Digitalmars-d]

On Sunday, 12 June 2016 at 10:51:16 UTC, Walter Bright wrote:

On 6/12/2016 3:17 AM, Chris wrote:

On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:

On 6/10/2016 3:55 AM, Chris wrote:
> Cool. I'd love to see `DScript` one day - and replace JS 
> once

and for all ...
> well ... just day dreaming ...

Dreams are reality:

https://github.com/DigitalMars/DMDScript


I just tried to compile it on Linux with dmd v2.071.0 in 64bit 
mode. The
compiler emits loads of deprecation warnings concerning module 
import,


Yeah, the import lookup was recently changed.


and it seems to be geared towards 32bit:


That's right. It should be fixed.

Nevertheless, these are minor issues. If you try to create a 
new script compiler, you're in for a heluva lot more work than 
fixing some bit rot.


Sure, but then we should turn it into a first class citizen and 
update it with each version of dmd and prevent bit rot.


I haven't had a chance to look at the source code in detail yet. 
How hard would it be to integrate JIT and D (and C) interop? 
Theoretically something like the Derelict-D libs allow for 
interop with Python and Lua too. I think we could create 
something really nice and useful here.


By the way, provided we go ahead with this, wouldn't the name 
DScript be catchier than DMSScript? Although I don't want to 
bikeshed about the name now.

Re: Why can't I assign a mixin to an alias?

[Dechcaudron via Digitalmars-d-learn]

On Saturday, 11 June 2016 at 01:53:10 UTC, David Nadlinger wrote:
This might be a gratuitous grammar restriction. There are a few 
of those surrounding alias "targets". A template that simply 
returns its parameter might work, though, such as 
std.meta.Alias (alias foo = Alias!(mixin(…));).


It seems to be that it would be a good idea to file this in as a 
suggested change/fix. Do I have support?

Re: Version identifier for PS4

[Markus Pursche via Digitalmars-d]

On Sunday, 12 June 2016 at 06:29:08 UTC, Walter Bright wrote:

On 6/9/2016 5:30 AM, Johan Engelen wrote:

Hi all,
  PR 5850 is proposing to add a predefined (reserved) version 
identifier for the

PS4 OS: "PS4" [1].
Thanks for your comment (preferably with an alternative 
suggestion in case you

don't like "PS4").

Thanks,
  Johan

[1] https://github.com/dlang/dmd/pull/5850


As others suggested, me kinda prefer "PlayStation4" as there's 
little doubt what that refers to.


As per popular request I have changed the commit to reserve 
"PlayStation" and "PlayStation4".


First of all, if what Johan says is right about "PlayStation" 
reserving all additions to the keyword as well (PlayStation4, 
PlayStation5, PlaystationOver9000) then my reasoning behind 
reserving "PlayStation4" is for claritys sake and for the 
documentation.


If it isn't right, "PlayStation" is a good keyword because there 
might be a possibility to reuse code between the PS4 and a 
theoretical future PS5.

Re: Passing private functions to template algorithms

[Dicebot via Digitalmars-d]

On 06/12/2016 01:55 PM, Timon Gehr wrote:
> On 12.06.2016 10:28, Dicebot wrote:
>> On 06/07/2016 09:59 PM, Timon Gehr wrote:
>>> I think it is obvious that this should work. Visibility checks need to
>>> happen during identifier lookup. This lookup is happening in the module
>>> where isFileNothrow is visible.
>>
>> My understanding is that right now template alias argument means
>> transparent symbol lookup. It acts as if doesn't access alias symbol in
>> template but aliased one directly.
>> ...
> 
> The lookup accesses the alias and is immediately rewritten to refer to
> the aliased symbol. Visibility checks should be applied during the
> lookup, but not after the rewrite.

Yes, that is natural solution but it makes alias itself first-class
symbol which leads to my example snippet question.

>> I agree such semantics are sub-optimal but changing that can break quite
>> some existing idioms. Consider this snippet for example:
>>
>> enum name ( alias sym ) = sym.stringof;
>>
>> Right now it evaluates to name of passed symbol.  If we change lookup
>> semantics to be non-transparent, it must always return `sym` for
>> consistency.
>>
> 
> I completely disagree that this would need to happen. E.g.
> fullyQualifiedName should work with private symbols just as well as with
> public ones.
> 
> Maybe this is helpful: https://en.wikipedia.org/wiki/Information_hiding

Private or public is irrelevant here, it seems you have misunderstood my
concern. The essential question is "what the alias is?", not how it is
accessed. There must be no special cases for aliases regarding
private/public symbol access, it is matter of defining actual alias
semantics so that generic access rules start being useful.

Re: Button: A fast, correct, and elegantly simple build system.

[Fool via Digitalmars-d-announce]

On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote:
I am pleased to finally announce the build system I've been 
slowly working on for over a year in my spare time:


Docs:   http://jasonwhite.github.io/button/
Source: https://github.com/jasonwhite/button

Features:

- Correct incremental builds.
- Automatic dependency detection (for any build task, even 
shell scripts).

- Build graph visualization using GraphViz.
- Language-independent. It can build anything.
- Can automatically build when an input file is modified (using 
inotify).
- Recursive: It can build the build description as part of the 
build.

- Lua is the primary build description language.


Nice work! I'm wondering how Button would compare in the Build 
System Shootout (https://github.com/ndmitchell/build-shootout).

Re: Passing private functions to template algorithms

[Timon Gehr via Digitalmars-d]

On 12.06.2016 10:28, Dicebot wrote:

On 06/07/2016 09:59 PM, Timon Gehr wrote:

I think it is obvious that this should work. Visibility checks need to
happen during identifier lookup. This lookup is happening in the module
where isFileNothrow is visible.


My understanding is that right now template alias argument means
transparent symbol lookup. It acts as if doesn't access alias symbol in
template but aliased one directly.
...


The lookup accesses the alias and is immediately rewritten to refer to 
the aliased symbol. Visibility checks should be applied during the 
lookup, but not after the rewrite.



I agree such semantics are sub-optimal but changing that can break quite
some existing idioms. Consider this snippet for example:

enum name ( alias sym ) = sym.stringof;

Right now it evaluates to name of passed symbol.  If we change lookup
semantics to be non-transparent, it must always return `sym` for
consistency.



I completely disagree that this would need to happen. E.g. 
fullyQualifiedName should work with private symbols just as well as with 
public ones.


Maybe this is helpful: https://en.wikipedia.org/wiki/Information_hiding

Re: I'd love to see DScript one day ...

[Walter Bright via Digitalmars-d]

On 6/12/2016 3:17 AM, Chris wrote:

On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:

On 6/10/2016 3:55 AM, Chris wrote:
> Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
> well ... just day dreaming ...

Dreams are reality:

https://github.com/DigitalMars/DMDScript


I just tried to compile it on Linux with dmd v2.071.0 in 64bit mode. The
compiler emits loads of deprecation warnings concerning module import,


Yeah, the import lookup was recently changed.


and it seems to be geared towards 32bit:


That's right. It should be fixed.

Nevertheless, these are minor issues. If you try to create a new script 
compiler, you're in for a heluva lot more work than fixing some bit rot.

[Issue 14496] void initialization of member with indirections must not be @safe

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/5861

--

Re: I'd love to see DScript one day ...

[Chris via Digitalmars-d]

On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:

On 6/10/2016 3:55 AM, Chris wrote:
> Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
> well ... just day dreaming ...

Dreams are reality:

https://github.com/DigitalMars/DMDScript


I just tried to compile it on Linux with dmd v2.071.0 in 64bit 
mode. The compiler emits loads of deprecation warnings concerning 
module import, and it seems to be geared towards 32bit:


[...]
engine/source/dmdscript/dstring.d(953,16): Deprecation: module 
std.string is not accessible here, perhaps add 'static import 
std.string;'
engine/source/dmdscript/expression.d(216,9): Warning: statement 
is not reachable
engine/source/dmdscript/expression.d(306,28): Deprecation: module 
std.ascii is not accessible here, perhaps add 'static import 
std.ascii;'
engine/source/dmdscript/expression.d(318,9): Error: static assert 
 (8LU == 4LU) is false

dmd failed with exit code 1.

The error message refers to:

`override void toIR(IRstate *irs, uint ret)
{
static assert((Identifier*).sizeof == uint.sizeof);  // 
<==

if(ret)
{
uint u = cast(uint)Identifier.build(string);
irs.gen2(loc, IRstring, ret, u);
}
}
`

[Issue 14496] void initialization of member with indirections must not be @safe

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 12857] Don't allow declaring @system function inside @safe block

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #6 from Walter Bright  ---
See closing of https://github.com/D-Programming-Language/dmd/pull/3623 and the
comments here as to why this is invalid.

--

Re: What's up with GDC?

[Johan Engelen via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:


Here are the versions

The one that isn't working:
LDC - the LLVM D compiler (30b1ed):
  based on DMD v2.071.1 and LLVM 3.9.0git-d06ea8a
  built with LDC - the LLVM D compiler (1.0.0)
  Default target: x86_64-pc-windows-msvc
  Host CPU: skylake
  http://dlang.org - http://wiki.dlang.org/LDC

The one that is:
B:\DLang\ldc2\bin>ldc2 -version
LDC - the LLVM D compiler (1.0.0):
  based on DMD v2.070.2 and LLVM 3.9.0git
  built with LDC - the LLVM D compiler (1.0.0)
  Default target: i686-pc-windows-msvc
  Host CPU: skylake
  http://dlang.org - http://wiki.dlang.org/LDC


The first one is a pre-alpha (!) version.
The second one is our latest released version, which is the one I 
recommend you to use.


If you want your bugs to be noted and fixed, you should try that 
test version and report bugs. That's kind of what you are doing 
now, so thanks ;)  Of course, clarity in reporting is important 
to get bugs fixed...

Re: I'd love to see DScript one day ...

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 12 June 2016 at 08:32:10 UTC, Dicebot wrote:

On 06/11/2016 01:01 AM, Walter Bright wrote:

On 6/10/2016 3:55 AM, Chris wrote:
Cool. I'd love to see `DScript` one day - and replace JS once 
and for

all ...

well ... just day dreaming ...


Dreams are reality:

https://github.com/DigitalMars/DMDScript


On a related topic - has anyone looked into what needs to be 
done to support D + WebAssembly combo?


WebAssembly is currently close to asm.js. In fact I believe 
WebAssembly is distilled from the asm.js backend.


Single threaded, no garbage collection support.

Re: What's up with GDC?

[Johan Engelen via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 04:19:33 UTC, Joerg Joergonson wrote:


So ldc parses things differently than dmd... I imagine this is 
a bug!


That, or you are comparing different D language versions.

The D language is evolving: different DMD compiler versions may 
treat the same code differently.

 ldc2 --version

LDC - the LLVM D compiler (683d9e):
  based on DMD v2.071.1 and LLVM 3.5.2svn-r255994
 ^^^
So this LDC version is compatible with the D-language spec of DMD 
2.071.
When comparing compilers on code they accept/decline, you have to 
compare the same language spec.

Re: What's up with GDC?

[Johan Engelen via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 03:11:14 UTC, Mike Parker wrote:

On Sunday, 12 June 2016 at 01:51:05 UTC, Joerg Joergonson wrote:


DMD works fine BTW. GDC and LDC should be a drop in 
replacement. Not a totally new setup that has it's own set of 
problems. I'm sure I'm not the only one put off by the 
compounding of problems when using D.


[...]
IIRC, LDC does recognize some DMD switches, and there is a tool 
called GDMD that allows you to invoke GDC as if you were 
invoking DMD, but you can't expect the compilers to be drop-in 
replacements for each other.


LDC has LDMD2 that accepts DMD-like parameters.

LDMD2 calls LDC2. Compiler options not recognized by LDMD2 are 
passed straight to LDC2, so you can pass LDC-specific options to 
LDMD2 too.

Re: I'd love to see DScript one day ...

[data man via Digitalmars-d]

On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:

On 6/10/2016 3:55 AM, Chris wrote:
> Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
> well ... just day dreaming ...


My crazy dream (or cool idea :): to use the DMD interpreter as 
the script engine!

[Issue 11176] array.ptr in @safe code may point past end of array

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #18 from Walter Bright  ---
https://github.com/dlang/dmd/pull/5860

--

Re: Transient ranges

[Dicebot via Digitalmars-d]

On Friday, 3 June 2016 at 12:03:26 UTC, Steven Schveighoffer 
wrote:
It only strengthens my opinion that Phobos is not a standard 
library I
want. Really, many of those issue would have been solved if 
basic input
range was defined as `empty` + `ElementType popFront()` 
instead.


This doesn't solve the problem. empty may not be knowable until 
you try to fetch the next element (for instance, i/o). A better 
interface would be bool getNext(ref ElementType), or 
Nullable!ElementType getNext(), or tuple!(bool, "eof", 
ElementType, "value") getNext().


Not necessarily, one can simply define that range processing 
requires checking `empty` both before and after getting next 
element (and that returned value is undefined if empty == true).


Though I do agree that returning `Optional!ElementType` would be 
even better.


Yes, I can see good reason why you would want this. Hm... a set 
of adapters which reduce a range to its lesser API would be 
useful here:


array.asInput.map

But an expectation for map should be that you want it to be 
exactly the same as the original, but with a transformation 
applied to each fetch of an element. I think it needs to 
provide random access if random access is provided to it.


That is matter of design philosophy. For me such basic library 
primitives warrant C++ attitude of "don't pay for what you don't 
ask for" - and everything else, including actual feature 
completeness, is of negligible importance compared to that. If 
keeping random access for map requires either caching or multiple 
evaluations of predicate, I want it to be banned by default and 
enabled explicitly (not sure what could be good API for that 
though).


Phobos indeed doesn't seem to make such priorities right now and 
that is one of reasons I am growing increasingly unhappy with it.


Then it's not a bug? It's going to work just fine how you 
specified
it. I just don't consider it a valid "range" for general 
purposes.


You can do this if you want caching:

only(0).map!(x => uniform(0, 10)).cache


Good advice. Don't want bugs with non-stable results and 
accidental
double I/O in your long idiomatic range pipeline? Just put 
"cache" calls

everywhere just to be safe, defensive programming for the win!


Strawman, not what I said.


But that is what your answer meant in context of my original 
question :) My complaint was about existing semantics are being 
error-prone and hard to spot - you proposed it by adding more 
_manual_ fixup, which kills the whole point.

Re: Fibers, what for?

[chmike via Digitalmars-d-learn]

On Sunday, 12 June 2016 at 05:11:57 UTC, Ali Çehreli wrote:


For convenience, here's the link:

  http://www.ustream.tv/recorded/86352137/highlight/699197

unfortunately iPads are not supported to view the video. :(

I see two major benefits of fibers overs threads.

Fibers don't need synchronization to access shared data. This 
removes the overhead of synchronization and simplifies 
"multitheaded" programming greatly.


The second benefit is that fibers have a much lower time cost of 
context switching. When a fiber yields the processor to another 
fiber, the switch is immediate and the other fiber can immediatly 
resume its task. With threads, you have to wait that the OS give 
the processor back to your process. This can take some time when 
there are many other threads competing for the processor. The 
performance difference is the most notable when the amount of 
work to do between switches is small.


Most popular and succesfull use for fibers is for asynchronous or 
event driven processing.

Re: I'd love to see DScript one day ...

[Dicebot via Digitalmars-d]

On 06/11/2016 01:01 AM, Walter Bright wrote:
> On 6/10/2016 3:55 AM, Chris wrote:
>> Cool. I'd love to see `DScript` one day - and replace JS once and for
> all ...
>> well ... just day dreaming ...
> 
> Dreams are reality:
> 
> https://github.com/DigitalMars/DMDScript

On a related topic - has anyone looked into what needs to be done to
support D + WebAssembly combo?

Re: Passing private functions to template algorithms

[Dicebot via Digitalmars-d]

On 06/07/2016 09:59 PM, Timon Gehr wrote:
> I think it is obvious that this should work. Visibility checks need to
> happen during identifier lookup. This lookup is happening in the module
> where isFileNothrow is visible.

My understanding is that right now template alias argument means
transparent symbol lookup. It acts as if doesn't access alias symbol in
template but aliased one directly.

I agree such semantics are sub-optimal but changing that can break quite
some existing idioms. Consider this snippet for example:

enum name ( alias sym ) = sym.stringof;

Right now it evaluates to name of passed symbol. If we change lookup
semantics to be non-transparent, it must always return `sym` for
consistency.

Re: Perl6 Unicode support

[ag0aep6g via Digitalmars-d-announce]

On 06/12/2016 05:16 AM, Andrew Godfrey wrote:

Eg it says ".chars returns the number of characters (aka graphemes)"

Does this count the number of graphemes, or the number of grapheme
clusters? Later on with \r\n it pretty much says that it counts grapheme
clusters. Here it says it counts graphemes.


Sorry, I still don't get it. Can you give an example string where 
counting graphemes gives a different result from counting grapheme clusters?