Re: blog.dlang.org

[Christian Köstlin via Digitalmars-d-learn]

On 22/06/16 01:51, Seb wrote:
> On Tuesday, 21 June 2016 at 23:36:41 UTC, Leandro Motta Barros wrote:
>> Try http://dlang.org/blog/
>>
>> But, indeed, I would expect blog.dlang.org to work...
>>
>> Cheers,
>>
>> LMB
>>
>> On Tue, Jun 21, 2016 at 6:47 PM, Christian Köstlin <
>> digitalmars-d-learn@puremagic.com> wrote:
>>
>>> I just wanted to have a look at the new blog post about ldc, and
>>> entered blog.dlang.org without thinking into the browser.
>>>
>>> This does not lead to the official blog anymore, but to the old
>>> digitalmars website.
> 
> Good catch - reported: https://github.com/dlang/D-Blog-Theme/issues/17 ;-)
thanks!
I was sure that there is a right way of reporting this.
Next time I will put up an issue on github.

christian

Re: Using .lib and .dll in D applications

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 22 June 2016 at 03:06:29 UTC, moe wrote:


I meant like this:

- PluginContract // not a dub project, just some folder
-- iplugin.d

- TestApp // all files for the app (separate project)
-- packages
 DerelictUtil-master // contains the project for derelict
-- source
 app.d // the app
-- dub.json // the project file for the app

The only dub project would be TestApp. PluginContract would 
just be some folder completely outside the TestApp dub project. 
I could not get a relative path to work like this.


Just to be clear, are you compiling iplugin.d as well? I assumed 
you were referring to a compiler error (i.e. missing import), but 
based on this post I would guess you're getting a linker error. 
You should probably add this to your dub.json in addition to the 
importPaths:


"sourceFiles": ["../PluginContract/iplugin.d"]

Re: problem using ldc 1.0.0 as D compiler

[Satoshi via Digitalmars-d]

On Tuesday, 21 June 2016 at 17:30:38 UTC, yawniek wrote:

On Tuesday, 21 June 2016 at 16:26:14 UTC, Satoshi wrote:

On Monday, 20 June 2016 at 11:28:58 UTC, Antonio Corbi wrote:

Hi folks!

I'm using ldc version:
LDC - the LLVM D compiler (1.0.0):
  based on DMD v2.070.2 and LLVM 3.8.0
  built with DMD64 D Compiler v2.071.0
  Default target: x86_64-unknown-linux-gnu
  Host CPU: core2

[...]


I have the same problem with LDC 1.1.0 on Arch Linux


you could use ldc-git from aur,
https://aur.archlinux.org/packages/ldc-git/
this has static phobos



I'm linking phobos and druntime into another shared lib then I'm 
using it in projects.

Real implicitly converts to float?

[Tofu Ninja via Digitalmars-d-learn]

Is this intended behavior? I can't seem to find it documented 
anywhere, I would think the loss in precision would atleast be a 
warning.


real x = 10;
float y = x; // No error or warning

real to double and double to float also work.

Re: Using .lib and .dll in D applications

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 22 June 2016 at 02:38:23 UTC, moe wrote:



Yes, I did it intentionally. I wanted to ensure that the 
packages are self contained and check whether it would work 
fine like this. Basically I like to have a project that 
contains everything it needs with the versions originally used 
to build. It sort of creates a reference for learning.


Understood. FYI, you can specify a specific version and dub 
upgrade won't touch it.





For testing I would have also liked not to build a dub project 
for the PluginContract but rather have a simple iplugins.d file 
in a folder. I could not get it to be imported if it's outside 
of a dub project.


"importPaths": ["../PluginContract"]

Did not work for some reason. But that's a minor issue.


Becuase you specified an incomplete path:

../PluginContract/source

The compiler needs the root directory of the root package for any 
imporyed module.

Re: Using .lib and .dll in D applications

[moe via Digitalmars-d-learn]

On Wednesday, 22 June 2016 at 01:40:47 UTC, Mike Parker wrote:

On Tuesday, 21 June 2016 at 23:59:54 UTC, moe wrote:
I had some time to try it out and I finally got it to work. I 
have only tried in windows so far but there was a pitfall in 
windows. Your dll need a DllMain entry to compile. This was 
the only thing that was missing from your information.


Right, I forgot about that. It's always optional in C and C++, 
but in D we need to use it to initialize the runtime.




-- TestApp // all files for the app (separate project)
 packages
-- DerelictUtil-master // contains the project for derelict
 source
-- app.d // the app
 dub.json // the project file for the app


This is not the way DerelictUtil, or any DUB package, is 
intended to be used when you use DUB to manage your project. 
You don't need to download it this way. You chould change your 
dependency in TestApp:




"dependencies": {
"derelict-util":  "version=~>2.0.6",


2.0.6 is the latest. The '~>' means >=2.0.6 && <2.1.0, so that 
if there is a 2.0.7 released, you can run 'dub upgrade' on your 
project and start using it. The same for 2.0.8, 2.0.9, 2.0.n...


Of course, if you have a reason for doing it that way, more 
power to you :)


Yes, I did it intentionally. I wanted to ensure that the packages 
are self contained and check whether it would work fine like 
this. Basically I like to have a project that contains everything 
it needs with the versions originally used to build. It sort of 
creates a reference for learning.


For testing I would have also liked not to build a dub project 
for the PluginContract but rather have a simple iplugins.d file 
in a folder. I could not get it to be imported if it's outside of 
a dub project.


"importPaths": ["../PluginContract"]

Did not work for some reason. But that's a minor issue.

Re: Timer

[Joerg Joergonson via Digitalmars-d-learn]

On Wednesday, 22 June 2016 at 01:31:17 UTC, Adam D. Ruppe wrote:
On Tuesday, 21 June 2016 at 23:15:58 UTC, Joerg Joergonson 
wrote:

Does D have a timer?


You could make one with threads or timeouts, or event loop and 
GUI libraries have one.


Like simpledisplay.d has a Timer class 
http://dpldocs.info/experimental-docs/arsd.simpledisplay.Timer.html and i'm sure the others do too.


I guess I'll just use that then ;)

Thanks again.

Re: dlang-requests 0.1.7 released

[Zekereth 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.


I have a couple of questions. If a url can't be found and I catch 
the ConnectError exception and handle it[2] I still get an 
additional error[1] printed. For example:


try
{
getContent(url);
}
catch(ConnectError ex)
{
debug writeln("Error getting page: ", ex.msg);
}

Will error with this:

[1]2016-06-21T20:59:15.073:streams.d:connect:750 Failed to 
connect: can't resolve www.systemcontrolpanel.com - getaddrinfo 
error: Name or service not known


[2]Error getting page: Can't connect to 
www.systemcontrolpanel.com:80: getaddrinfo error: Name or service 
not known


The additional error[1] will still print in release build. The 
only workaround I could find was to check getAddress myself and 
ensure that the page exists before calling getContent.


Thanks!

Re: Examples of dub use needed

[Mike Parker via Digitalmars-d]

On Tuesday, 21 June 2016 at 15:02:01 UTC, Guido wrote:



I'm the sort of person who learns by example, and what I was 
saying is that there aren't enough examples online of how dub 
is used in a practical setting.


There aren't that many commands for DUB on the command line. Most 
of what you need can be gleaned from dub --help, but there is 
also documentation online [1]. For package configurations, the 
documentation at code.dlang.org covers everything [2] & [3], just 
not always clearly. It's easy enough to get examples for that 
from all of the projects listed in the registry [4]. Just click 
through them to their github or bitbucket repositories and study 
their dub.json/sdl files. And there's always the DUB forums [5.




I'm also the sort of person who doesn't trust toolchains that 
need to download things every time from the internet just to 
compile. Is this what dub is doing? In other words, when a 
project is built using dub, does it use the local cache from 
the last build by default, check for later versions, pull 
things from the internet, etc? Or do I need -cache=local for 
that?


DUB only downloads a package when it first needs it. It will only 
update to a newer version for a given project if you run 'dub 
upgrade' on that project. Given a project foo which relies on DUB 
package libbar 1.0.0:


cd foo
dub build <-- checks if libbar 1.0.0 is in the cache, finds it 
missing, downloads it

dub build <-- checks if libbar 1.0.0 is in the cache, finds it
dub upgrade <-- checks if the latest version is in the cache. If 
not, downloads it
according to how you have specified your 
dependency (see [6])



[1] 
https://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/

[2] https://code.dlang.org/package-format?lang=json
[3] https://code.dlang.org/package-format?lang=sdl
[4] https://code.dlang.org/
[5] http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/
[6] https://github.com/dlang/dub/wiki/Version-management

Re: Using .lib and .dll in D applications

[Mike Parker via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 23:59:54 UTC, moe wrote:
I had some time to try it out and I finally got it to work. I 
have only tried in windows so far but there was a pitfall in 
windows. Your dll need a DllMain entry to compile. This was the 
only thing that was missing from your information.


Right, I forgot about that. It's always optional in C and C++, 
but in D we need to use it to initialize the runtime.




-- TestApp // all files for the app (separate project)
 packages
-- DerelictUtil-master // contains the project for derelict
 source
-- app.d // the app
 dub.json // the project file for the app


This is not the way DerelictUtil, or any DUB package, is intended 
to be used when you use DUB to manage your project. You don't 
need to download it this way. You chould change your dependency 
in TestApp:




"dependencies": {
"derelict-util":  "version=~>2.0.6",


2.0.6 is the latest. The '~>' means >=2.0.6 && <2.1.0, so that if 
there is a 2.0.7 released, you can run 'dub upgrade' on your 
project and start using it. The same for 2.0.8, 2.0.9, 2.0.n...


Of course, if you have a reason for doing it that way, more power 
to you :)

Re: Timer

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

On Tuesday, 21 June 2016 at 23:15:58 UTC, Joerg Joergonson wrote:

Does D have a timer?


You could make one with threads or timeouts, or event loop and 
GUI libraries have one.


Like simpledisplay.d has a Timer class 
http://dpldocs.info/experimental-docs/arsd.simpledisplay.Timer.html and i'm sure the others do too.

Re: blog.dlang.org

[Mike Parker via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 21:47:46 UTC, Christian Köstlin wrote:
I just wanted to have a look at the new blog post about ldc, 
and entered blog.dlang.org without thinking into the browser.


This does not lead to the official blog anymore, but to the old 
digitalmars website.


When we first set up the blog, we decided not to use a new 
subdomain for it. I don't think anyone involved realized it 
already existed. Since it does, I guess that means we'll just 
redirect it.

[Issue 16189] Optimizer bug, with simple test case

[via Digitalmars-d-bugs]

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

--- Comment #2 from Kirill Kryukov  ---
A possible workaround: change "a--;" into "{ auto a2 = a - 1; a = a2; }".

(This is NOT to suggest that the bug does not need fixing, as it's annoying as
hell that even simplest C-like code does not work correctly.)

As for previous reduction - it hurts my eyes to see size_t (unsigned type)
compared for equality with -1, so I suggest to at least use ptrdiff_t.

--

Re: Using .lib and .dll in D applications

[moe via Digitalmars-d-learn]

I had some time to try it out and I finally got it to work. I 
have only tried in windows so far but there was a pitfall in 
windows. Your dll need a DllMain entry to compile. This was the 
only thing that was missing from your information. The rest 
worked perfectly. This may be obvious to most around here, but I 
did not know before. So, I thought it might make sense to show my 
working solution in case someone else stumbles upon the same 
problem.


I wanted the app and the plugin to be independent projects form 
one another. So they both need a shared project containing the 
interface for the plugin. That makes the 3 projects shown below. 
I can than after compiling the app simply copy the plugin dll 
into a plugins folder and the app will find it on demand. So that 
I could later add more plugins if desired. Obviously in that case 
I would have to get a list of available plugins by reading the 
filenames in the plugins directory instead of a hard coded path 
in the app. I tried to reduce it to the bare minimum with a 
working solution. Even with the DllMain entry (which is necessary 
for windows) it turns out to be surprisingly compact.


There are 3 distinct projects. I have the following directories 
(omitting some generated by dub):


- PluginTest

-- PluginContract // all files for the shared plugin interface 
(separate project)

 source
-- iplugin.d // the interface for the plugin
 dub.json // the project file for the shared plugin interface

-- TestApp // all files for the app (separate project)
 packages
-- DerelictUtil-master // contains the project for derelict
 source
-- app.d // the app
 dub.json // the project file for the app

-- TestPlugin // all files for the plugin (separate project)
 source
-- someplugin.d // the plugin
 dub.json // the project file for the plugin


Here are the files:

Shared plugin interface (Project 1)
===
Note, these are necessary for the linker to find the files:
"targetType": "library"
"targetPath": "lib"

PluginTest/PluginContract/dub.json
--
{
"name": "plugincontract",
"authors": ["root"],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, root",
"license": "proprietary",
"platforms": ["windows"],
"versions": ["DesktopApp"],
"targetType": "library",
"configurations": [
{
"name": "debug",
"targetPath": "lib",
"buildOptions": ["debugMode", "debugInfo"],
},
{
"name": "release",
"targetPath": "lib",
"buildOptions": ["releaseMode", "optimize", "inline"],
}
]
}


PluginTest/PluginContract/source/iplugin.d
--
module iplugin;

interface IPlugin
{
void Talk(string msg);
}





TestApp (Project 2)
===

PluginTest/TestApp/dub.json
---
{
"name": "testapp",
"authors": ["root"],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, root",
"license": "proprietary",
"platforms": ["windows"],
"versions": ["DesktopApp"],
"targetType": "executable",
"dependencies": {
"derelict-util":  {"path": "packages/DerelictUtil-master"},
"plugincontract": {"path": "../PluginContract"}
},
"configurations": [
{
"name": "debug",
"targetPath": "bin/debug",
"buildOptions": ["debugMode", "debugInfo"],
},
{
"name": "release",
"targetPath": "bin/release",
"buildOptions": ["releaseMode", "optimize", "inline"],
}
]
}


PluginTest/TestApp/source/app.d
---
import std.stdio;
import derelict.util.sharedlib;
import iplugin;

alias GetPluginImpl = extern(C) nothrow IPlugin function();
GetPluginImpl getPlugin;

void main()
{
SharedLib lib;
lib.load(["plugins/testplugin.dll"]);
getPlugin = cast(GetPluginImpl)lib.loadSymbol("getPlugin");

auto plugin = getPlugin();
plugin.Talk("Hello World.");

writeln("End of app.");
}




TestPlugin (Project 3)
==

PluginTest/TestPlugin/dub.json
--
{
"name": "testplugin",
"authors": ["root"],
"description": "A minimal D application.",
"copyright": "Copyright © 2016, root",
"license": "proprietary",
"platforms": ["windows"],
"versions": ["DesktopApp"],
"targetType": "dynamicLibrary",
"importPaths": ["../PluginContract"],
"dependencies": {
"plugincontract": {"path": "../PluginContract"}
},
"configurations": [
{
"name": 

Re: blog.dlang.org

[Seb via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 23:36:41 UTC, Leandro Motta Barros 
wrote:

Try http://dlang.org/blog/

But, indeed, I would expect blog.dlang.org to work...

Cheers,

LMB

On Tue, Jun 21, 2016 at 6:47 PM, Christian Köstlin < 
digitalmars-d-learn@puremagic.com> wrote:


I just wanted to have a look at the new blog post about ldc, 
and entered blog.dlang.org without thinking into the browser.


This does not lead to the official blog anymore, but to the 
old digitalmars website.


Good catch - reported: 
https://github.com/dlang/D-Blog-Theme/issues/17 ;-)

Re: blog.dlang.org

[Leandro Motta Barros via Digitalmars-d-learn]

Try http://dlang.org/blog/

But, indeed, I would expect blog.dlang.org to work...

Cheers,

LMB

On Tue, Jun 21, 2016 at 6:47 PM, Christian Köstlin <
digitalmars-d-learn@puremagic.com> wrote:

> I just wanted to have a look at the new blog post about ldc, and entered
> blog.dlang.org without thinking into the browser.
>
> This does not lead to the official blog anymore, but to the old
> digitalmars website.
>
>

Timer

[Joerg Joergonson via Digitalmars-d-learn]

Does D have a timer? I've tried some user code and it doesn't 
work. I need to be able to have a delegate called periodically. 
(fiber or thread, doesn't matter)




https://github.com/Dav1dde/BraLa/blob/master/brala/utils/thread.d




module lib.mTimer;

private
{
import std.traits : ParameterTypeTuple, isCallable;
import std.string : format;
import core.time : Duration;
import core.sync.mutex : Mutex;
import core.sync.condition : Condition;


import std.stdio : stderr;
}

public import core.thread;


private enum CATCH_DELEGATE = `
delegate void() {
try {
fun();
} catch(Throwable t) {
stderr.writefln("--- Exception in Thread: \"%s\" 
---".format(this.name));

stderr.writeln(t.toString());
stderr.writefln("--- End Exception in Thread 
\"%s\" ---".format(this.name));


throw t;
}
}
`;

class VerboseThread : Thread
{
this(void function() fun, size_t sz = 0)
{
super(mixin(CATCH_DELEGATE), sz);
}

this(void delegate() fun, size_t sz = 0)
{
super(mixin(CATCH_DELEGATE), sz);
}
}

class TTimer(T...) : VerboseThread
{
static assert(T.length <= 1);
static if(T.length == 1)
{
static assert(isCallable!(T[0]));
alias ParameterTypeTuple!(T[0]) Args;
} else
{
alias T Args;
}

public Duration interval;
protected Args args;
protected void delegate(Args) func;

protected Event finished;
@property bool is_finished() { return finished.is_set; }


this(Duration interval, void delegate(Args) func, Args args)
{
super();

finished = new Event();

this.interval = interval;
this.func = func;

static if(Args.length) {
this.args = args;
}
}

final void cancel()
{
finished.set();
}

protected void run()
{
finished.wait(interval);

if(!finished.is_set)
{
func(args);
}

finished.set();
}

}




class Event
{
protected Mutex mutex;
protected Condition cond;

protected bool flag;
@property bool is_set() { return flag; }

this()
{
mutex = new Mutex();
cond = new Condition(mutex);

flag = false;
}

void set()
{
mutex.lock();
scope(exit) mutex.unlock();

flag = true;
cond.notifyAll();
}

void clear()
{
mutex.lock();
scope(exit) mutex.unlock();

flag = false;
}

bool wait(T...)(T timeout) if(T.length == 0 || (T.length == 1 
&& is(T[0] : Duration)))

{
mutex.lock();
scope(exit) mutex.unlock();

bool notified = flag;
if(!notified)
{
static if(T.length == 0)
{
cond.wait();
notified = true;
} else
{
notified = cond.wait(timeout);
}
}
return notified;
}
}

Re: Release DUB 1.0.0

[WhatMeWorry via Digitalmars-d-announce]

On Tuesday, 21 June 2016 at 10:57:45 UTC, Saurabh Das wrote:

On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote:
I'm pleased to announce the release of the first stable 
version of the DUB package manager. Stable in this case means 
that the API, the command line interface and the package 
recipe format will only receive fully backwards compatible 
changes and additions for a while.


[...]


Congratulations on v1.0.0 and thank you for making and 
maintaining DUB! :)


Saurabh


+10

[Issue 16190] to!string on enum should be fully qualified for consistency

[via Digitalmars-d-bugs]

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com
  Component|dmd |phobos

--

blog.dlang.org

[Christian Köstlin via Digitalmars-d-learn]

I just wanted to have a look at the new blog post about ldc, and entered
blog.dlang.org without thinking into the browser.

This does not lead to the official blog anymore, but to the old
digitalmars website.

Re: problem using ldc 1.0.0 as D compiler

[Dicebot via Digitalmars-d]

On Tuesday, 21 June 2016 at 21:43:16 UTC, David Nadlinger wrote:

On Tuesday, 21 June 2016 at 16:26:14 UTC, Satoshi wrote:

On Monday, 20 June 2016 at 11:28:58 UTC, Antonio Corbi wrote:

Hi folks!

I'm using ldc version:
LDC - the LLVM D compiler (1.0.0):
  based on DMD v2.070.2 and LLVM 3.8.0
  built with DMD64 D Compiler v2.071.0
  Default target: x86_64-unknown-linux-gnu
  Host CPU: core2

[...]


I have the same problem with LDC 1.1.0 on Arch Linux


A fix for this just landed in Git master: 
https://github.com/ldc-developers/ldc/commit/6de981af757b00a91b36ae94d9ce9a8a81cfabf9


It would be great if you could build LDC yourself to verify 
that the issue is gone – be sure to open another ticket if the 
issue persists!


Would you mind making a point release with it if fix is confirmed?

Re: problem using ldc 1.0.0 as D compiler

[David Nadlinger via Digitalmars-d]

On Tuesday, 21 June 2016 at 16:26:14 UTC, Satoshi wrote:

On Monday, 20 June 2016 at 11:28:58 UTC, Antonio Corbi wrote:

Hi folks!

I'm using ldc version:
LDC - the LLVM D compiler (1.0.0):
  based on DMD v2.070.2 and LLVM 3.8.0
  built with DMD64 D Compiler v2.071.0
  Default target: x86_64-unknown-linux-gnu
  Host CPU: core2

[...]


I have the same problem with LDC 1.1.0 on Arch Linux


A fix for this just landed in Git master: 
https://github.com/ldc-developers/ldc/commit/6de981af757b00a91b36ae94d9ce9a8a81cfabf9


It would be great if you could build LDC yourself to verify that 
the issue is gone – be sure to open another ticket if the issue 
persists!


 — David

Re: Examples of dub use needed

[ZombineDev via Digitalmars-d]

On Tuesday, 21 June 2016 at 20:38:05 UTC, poliklosio wrote:

On Tuesday, 21 June 2016 at 08:58:59 UTC, Dicebot wrote:
But it is indeed supposed to be rare case and I do recommend 
to install such tools via system package manager instead 
whenever possible. So yes, you don't need `dub fetch` at all 
for most part.


Yes, it is best not to interfere with system package managers 
if they exist. On the other hand how do you install end-user 
tools like dcd, dfmt on windows, other than git clone + build?


I'm wondering why are packages updated so rarely on the dub 
repository?

For example I have dfmt 0.5.0, while dub fetch installs 0.4.5


`dub fetch` downloads the latest stable version if the 
`--version=` option is not specified. dfmt 0.5.0 is still in 
beta, according to latest tag in the repository.
`dub search` on the other hand lists only the latest version, so 
you can use that (in combination with `dub fetch --version=`) to 
get the latest version.

Re: opDispatch and @property setters

[Lodovico Giaretta via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 21:11:39 UTC, ag0aep6g wrote:
Works when you change the return type of the the @property 
opDispatch to auto, so that it can return the result. It's a 
little weird, but D does support calling functions with 
assignment syntax.


Alternatively, maybe you can actually check for the @property 
attribute in hasAssignableProperty. See 
FunctionAttribute/functionAttributes in std.traits [1]. I 
haven't tested this.



[1] http://dlang.org/phobos/std_traits.html#.FunctionAttribute


Thank you very much!

I managed to get it to work by using this code:

@property auto opDispatch(string name, Arg)(Arg arg)
{
mixin("return _p_data." ~ name ~ " = arg;");
}

It's a little weird, but D does support calling functions with 
assignment syntax.


Definitely strange.

Re: inout and opApply

[Timon Gehr via Digitalmars-d]

On 20.06.2016 17:09, Steven Schveighoffer wrote:


What I would like the compiler to do (and I went over this in my talk),
is to allow the compiler to inout-wrap a delegate along with the other
inout prameters to the function. That is, for:

int opApply(scope int delegate(ref inout T value) dg) inout

The inout inside the delegate is wrapped just like the inout of the
'this' parameter. effectively, this becomes equivalent to several
function signatures:

int opApply(scope int delegate(ref T value) dg)
int opApply(scope int delegate(ref const T value) dg) const
int opApply(scope int delegate(ref immutable T value) dg) immutable
int opApply(scope int delegate(ref inout T value) dg) inout

And interestingly enough, the rules are kind of backwards for delegates
-- while inout doesn't cast to anything, delegates with inout parameters
can cast to any type of mutability modifier (I believe this is called
contravariance). This is because the actual function is inout, so it
cannot harm the mutability. So something like this:

foreach(inout a; anyV1)
{
}

should work for any flavor of V1.

I think this should work with existing code, and would simply open up
things like opApply to inout support.

The only issue is that the compiler has to assume that while calling the
delegate, the inout parameters passed COULD change value, because it
doesn't know whether the passed delegate is truly inout, or just matches
the constancy of the type, which could potentially be mutable. This
differs from current expectations of inout delegate or function pointers.

It's a lot of complex explanation, but the end result is that you could
simply tag your opApply's with inout and have one version for all modifiers.


The problem here is that both variants make sense depending on context 
and there is no syntax to distinguish between them. This proposal 
interacts in a weird way with IFTI.

Re: opDispatch and @property setters

[ag0aep6g via Digitalmars-d-learn]

On 06/21/2016 10:48 PM, Lodovico Giaretta wrote:

 struct Wrapper(T)
 {
 private T wrapped;

 template hasAssignableProperty(string name, Arg)
 {
 enum bool hasAssignableProperty = is(typeof(
 (ref T val, ref Arg arg)
 {
 mixin("val." ~ name ~ " = arg;");
 }));
 }

 @property void opDispatch(string name, Arg)(Arg arg)
 if (hasAssignableProperty!(name, Arg))
 {
 pragma(msg, "@property ", name, " ", Arg);
 mixin("return wrapped." ~ name ~ " = arg;");
 }
 auto opDispatch(string name, Args...)(Args args)
 {

[...]

 }
 }

[...]

 struct Foo
 {

[...]

 int baz(int val) { return val; } // <-- method with exactly one
argument
 }

 void main()
 {

[...]

 int bazres = wf.baz(42); // ERROR: no property 'baz' (it's
trying to use the first opDispatch overload, while the second would be ok)
 }

Any way around this issue?


Works when you change the return type of the the @property opDispatch to 
auto, so that it can return the result. It's a little weird, but D does 
support calling functions with assignment syntax.


Alternatively, maybe you can actually check for the @property attribute 
in hasAssignableProperty. See FunctionAttribute/functionAttributes in 
std.traits [1]. I haven't tested this.



[1] http://dlang.org/phobos/std_traits.html#.FunctionAttribute

Re: Need DMD AST expertise

[Guillaume Chatelet via Digitalmars-d]

On Tuesday, 21 June 2016 at 19:42:54 UTC, Elie Morisse wrote:
On Monday, 20 June 2016 at 20:52:02 UTC, Guillaume Chatelet 
wrote:

[...]


The templated function is the child symbol of the 
TemplateDeclaration which shares the same name i.e


[...]


Thx Elie! It helps :)

I came up with this quick and dirty piece of code to get the 
parameters from the template declaration and the function 
declaration:


code:
auto declaration = 
cast(TemplateDeclaration)templateInstance.tempdecl;

assert(declaration);
printf("TemplateDeclaration %x\n", declaration);
foreach(parameter; *declaration.parameters) {
printf("Parameter %s\n", parameter.ident.toChars());
}

if (declaration.onemember) {
FuncDeclaration fd = 
declaration.onemember.isFuncDeclaration();

if (fd && fd.type) {
TypeFunction tf = cast(TypeFunction)fd.type;
assert(tf);
printf("TypeFunction %x\n", tf);
if(tf.next) printf("Parameter return %s\n", 
tf.next.toChars());

if(tf.parameters) foreach(parameter; *tf.parameters) {
printf("Parameter %s\n", parameter.type.toChars());
}
}
}


input:

extern(C++) C foo(A, B, C)(B, A);


output:

TemplateDeclaration 764f76b0
Parameter A
Parameter B
Parameter C
TypeFunction 764f7370
Parameter return C
Parameter B
Parameter A


It works as expected. I still need to do the mapping and handle 
subtleties like this but I'm on the right track.

extern(C++) ref C foo(A, B, C)(B*, const(A)*);


Thx!

opDispatch and @property setters

[Lodovico Giaretta via Digitalmars-d-learn]

Hi,

I'm trying to achieve perfect forwarding of any invocation from 
the wrapper to the wrapped item, but I'm having a bad time with 
@property.


Suppose this is my wrapper (with all logic stripped):

struct Wrapper(T)
{
private T wrapped;

template hasAssignableProperty(string name, Arg)
{
enum bool hasAssignableProperty = is(typeof(
(ref T val, ref Arg arg)
{
mixin("val." ~ name ~ " = arg;");
}));
}

@property void opDispatch(string name, Arg)(Arg arg)
if (hasAssignableProperty!(name, Arg))
{
pragma(msg, "@property ", name, " ", Arg);
mixin("return wrapped." ~ name ~ " = arg;");
}
auto opDispatch(string name, Args...)(Args args)
{
static if (Args.length > 0)
{
pragma(msg, name, " ", Args);
mixin("return wrapped." ~ name ~ "(args);");
}
else
{
pragma(msg, name);
mixin("return wrapped." ~ name ~ ";");
}
}
}

It correctly handles any property, but the existence of the 
@property setter dispatcher makes me unable to use any method 
that accepts just one parameter, because the compiler tries to 
resolve it with the first opDispatch overload, misinterpreting it 
as a setter call.


Here is an example:

struct Foo
{
private int _x;
@property int x() { return _x; }
@property void x(int newx) { _x = newx; }

long foo(string a, double b) const { return 0; }
void bar() {}
int baz(int val) { return val; } // <-- method with 
exactly one argument

}

void main()
{
alias WrappedFoo = Wrapper!Foo;
WrappedFoo wf;

wf.x = 3;
assert(wf.x == 3);

long foores = wf.foo("hello", 3.14);
wf.bar;

int bazres = wf.baz(42); // ERROR: no property 'baz' 
(it's trying to use the first opDispatch overload, while the 
second would be ok)

}

Any way around this issue?

Thank you in advance, and sorry if the question is silly and I'm 
just missing something stupid.


Lodovico Giaretta

Re: Examples of dub use needed

[poliklosio via Digitalmars-d]

On Tuesday, 21 June 2016 at 08:58:59 UTC, Dicebot wrote:
But it is indeed supposed to be rare case and I do recommend to 
install such tools via system package manager instead whenever 
possible. So yes, you don't need `dub fetch` at all for most 
part.


Yes, it is best not to interfere with system package managers if 
they exist. On the other hand how do you install end-user tools 
like dcd, dfmt on windows, other than git clone + build?


I'm wondering why are packages updated so rarely on the dub 
repository?

For example I have dfmt 0.5.0, while dub fetch installs 0.4.5

Re: Phobos Action Items

[Lodovico Giaretta via Digitalmars-d]

On Monday, 20 June 2016 at 07:48:49 UTC, Andrea Fontana wrote:

On Saturday, 18 June 2016 at 20:04:50 UTC, Walter Bright wrote:

6. replace std.xml with something we can be proud of that is 
second to none in performance (Robert burner Schadek is 
mentoring on this https://github.com/lodo1995/experimental.xml)


I hope it will support html and xpath too.

Andrea


The low-level parser is explicitly written to support any format 
which resembles XML, and will have no problem handling HTML. 
Regarding higher level APIs: with validations turned on, HTML 
would surely be rejected (it breaks many XML well-formedness 
constraints); with validations turned off, it may or may not 
work, because higher level APIs implicitly assume that their 
input is well-formed.


As for XPath, I probably won't have time to work on it during 
GSoC, but if everything goes well I may work on it after the end 
of the project.


Lodovico Giaretta

Re: D-Man culture

[Walter Bright via Digitalmars-d-announce]

On 6/19/2016 4:29 PM, Adam D. Ruppe wrote:

We should probably make a D-man video game.


Having one D-Man comic per This Week In D would be nice!

[Issue 16191] New: std/digest/digest.d should be renamed to package.d

[via Digitalmars-d-bugs]

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

  Issue ID: 16191
   Summary: std/digest/digest.d should be renamed to package.d
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

The fully qualified name of the digest function template
(https://dlang.org/phobos/std_digest_digest.html#digest) is
std.digest.digest.digest. This is because std.digest is a package, with a
module named digest in it, and the function digest inside that.

I think it's reasonable to have std.digest.digest. Even though there's
repetition, it's clear that the first digest is a module, the second is a
function name. But there's no reason (especially with the advent of package.d)
to have a std.digest.digest module.

--

Re: DLang users telegram group

[Oleg B via Digitalmars-d-announce]

On Tuesday, 8 December 2015 at 17:51:01 UTC, Kingsley wrote:
On Monday, 30 November 2015 at 10:58:34 UTC, Quentin Ladeveze 
wrote:

Hi everybody,

I just created a Telegram group for dlang users : 
https://telegram.me/joinchat/BeLaugMz35ZxQUq2fks4YQ


Feel free to join !


says the link has expired


yet another english group https://telegram.me/dlangTelegram

Re: Fiber implementation questions

[Steven Schveighoffer via Digitalmars-d]

On 6/21/16 3:03 PM, David Nadlinger wrote:

On Tuesday, 21 June 2016 at 16:12:13 UTC, Steven Schveighoffer wrote:

On 6/21/16 11:43 AM, Dicebot wrote:

On Tuesday, 21 June 2016 at 12:18:37 UTC, Steven Schveighoffer wrote:

On 6/21/16 6:14 AM, Dicebot wrote:
httpthub.com/dlang/druntime/blob/master/src/core/thread.d#L1611



I suspected something like this, it explains a lot. Do you know why this
approach was chosen instead of simply registering allocated memory for
GC scan? Does GC has special approach for stack scanning which differs
from normal memory?


There must be a reason, I think maybe Martin or Sean would know more.


You don't want to be scanning the unused part of the stack region. -David


OK, that's... pretty obvious, thanks :)

-Steve

Re: Need DMD AST expertise

[Elie Morisse via Digitalmars-d]

On Tuesday, 21 June 2016 at 19:42:54 UTC, Elie Morisse wrote:
On Monday, 20 June 2016 at 20:52:02 UTC, Guillaume Chatelet 
wrote:

« (cast(TypeFunction) fd->type)->parameters »


Mixing C++ and D once more..

Re: Need DMD AST expertise

[Elie Morisse via Digitalmars-d]

On Monday, 20 June 2016 at 20:52:02 UTC, Guillaume Chatelet wrote:
I'll have a look at `parameters` from TemplateDeclaration [2] 
but I still need to match it to the function arguments somehow.


The templated function is the child symbol of the 
TemplateDeclaration which shares the same name i.e


  Dsymbol* s;
  Dsymbol.oneMembers(tempdecl->members, , tempdecl->ident);
  auto fd = cast(FuncDeclaration) s;

You then need to visit the templated function parameters « 
(cast(TypeFunction) fd->type)->parameters » and look for 
identifiers that match the TemplateDeclaration.parameters[].ident.


In the simplest cases the types of templated function parameters 
are TypeIdentifier.

Re: Initialise dynamic array in array of structures

[ketmar via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 19:33:31 UTC, cym13 wrote:
i would want him to figure that by himself, tbh. just to remember 
that "{}" struct initialization is BAD. ;-)

Re: Initialise dynamic array in array of structures

[cym13 via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 19:15:56 UTC, Paul wrote:

Given these structures and declaration:

struct CoordList{
int x, y;
}

struct Part{
int x, y;
CoordList[] coords;
int nextNode, prevNode;
string nextEnter, prevEnter;
}

Part[10] trackTemplates;


Can someone please tell me why I can't initialise 
Part[0].coords like this:


trackTemplates[0].coords = [ {0, 9}, {1, 1}, {3, 6} ];

but I can do this:

CoordList[] temp = [ {0, 9}, {1, 1}, {3, 6} ];
trackTemplates[0].coords = temp;

Many thanks!


My take is that “CoordList[] temp = [{0, 9}, {1, 1}, {3, 6}];” is 
initialization because you're setting the value when defining it 
but “trackTemplates[0].coords = [{0, 9}, {1, 1}, {3, 6}];” is an 
assignment so the compiler can infer as much and doesn't 
understand that each of those list of values are really 
CoordLists. For example “trackTemplates[0].coords = 
[CoordList(0, 9), CoordList(1, 1), CoordList(3, 6)];” would have 
worked as expected.

Re: Initialise dynamic array in array of structures

[ketmar via Digitalmars-d-learn]

trackTemplates[0].coords = [ CoordList(0, 9), CoordList(1, 1), 
CoordList(3, 6) ];

Re: Is there anyway to make opApply @nogc?

[Gary Willoughby via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 12:53:11 UTC, Adam D. Ruppe wrote:

On Tuesday, 21 June 2016 at 12:48:04 UTC, Gary Willoughby wrote:
I have no idea what that means. Can anyone shed more light on 
this, please?


So when you use local variables in a delegate, the compiler 
usually makes a copy of them just in case the delegate gets 
saved for later.


When you mark it scope, you promise that you won't save it for 
later, so the compiler skips making the copy.


Right ok, thanks! It doesn't seem to help though as the compiler 
complains about it being not @nogc.

Re: D-Man culture

[Meta via Digitalmars-d-announce]

On Tuesday, 21 June 2016 at 19:13:09 UTC, Meta wrote:
On Monday, 20 June 2016 at 14:14:06 UTC, Martin Tschierschke 
wrote:

On Sunday, 19 June 2016 at 15:01:33 UTC, Seb wrote:

Hi,

I am not sure how much you have heard about the D-Man, but in 
Japan there is an entire culture based on the D-Man!
As I learned about this by accident (and even Walter didn't 
know about it), I thought I share this great movement with 
the DLang community!

[...]
Funny stuff!

I found this link useful: http://dlangcomicstrips.tumblr.com/


Ha, some of these critiques are scathing.

http://dlangcomicstrips.tumblr.com/image/144812160012


These are absolutely hilarious. We should include one with each 
issue of TWiD.


http://dlangcomicstrips.tumblr.com/image/124763618912

Initialise dynamic array in array of structures

[Paul via Digitalmars-d-learn]

Given these structures and declaration:

struct CoordList{
int x, y;
}

struct Part{
int x, y;
CoordList[] coords;
int nextNode, prevNode;
string nextEnter, prevEnter;
}

Part[10] trackTemplates;


Can someone please tell me why I can't initialise Part[0].coords 
like this:


trackTemplates[0].coords = [ {0, 9}, {1, 1}, {3, 6} ];

but I can do this:

CoordList[] temp = [ {0, 9}, {1, 1}, {3, 6} ];
trackTemplates[0].coords = temp;

Many thanks!

TickDuration depreciated, yet stopwatch not?

[Joerg Joergonson via Digitalmars-d-learn]

Stopwatch depends on TickDuration and TickDuration is depreciated 
yet Stopwatch isn't and hasn't been converted to MonoTime... 
makes sense?

Re: D-Man culture

[Meta via Digitalmars-d-announce]

On Monday, 20 June 2016 at 14:14:06 UTC, Martin Tschierschke 
wrote:

On Sunday, 19 June 2016 at 15:01:33 UTC, Seb wrote:

Hi,

I am not sure how much you have heard about the D-Man, but in 
Japan there is an entire culture based on the D-Man!
As I learned about this by accident (and even Walter didn't 
know about it), I thought I share this great movement with the 
DLang community!

[...]
Funny stuff!

I found this link useful: http://dlangcomicstrips.tumblr.com/


Ha, some of these critiques are scathing.

http://dlangcomicstrips.tumblr.com/image/144812160012

Re: Fiber implementation questions

[David Nadlinger via Digitalmars-d]

On Tuesday, 21 June 2016 at 16:12:13 UTC, Steven Schveighoffer 
wrote:

On 6/21/16 11:43 AM, Dicebot wrote:
On Tuesday, 21 June 2016 at 12:18:37 UTC, Steven Schveighoffer 
wrote:

On 6/21/16 6:14 AM, Dicebot wrote:
httpthub.com/dlang/druntime/blob/master/src/core/thread.d#L1611



I suspected something like this, it explains a lot. Do you 
know why this
approach was chosen instead of simply registering allocated 
memory for
GC scan? Does GC has special approach for stack scanning which 
differs

from normal memory?


There must be a reason, I think maybe Martin or Sean would know 
more.


You don't want to be scanning the unused part of the stack 
region. -David

[Issue 16190] to!string on enum should be fully qualified for consistency

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
   Hardware|x86 |All
 OS|Mac OS X|All

--- Comment #1 from b2.t...@gmx.com ---
I think that any fix directly in to() can break a lot of code because currently
to!string and to!E work together. I'm sure that it's already used as it is now
by many people.

The fix, if any, should maintain the old behvior and allow to get the
identifier when explicitly needed, for example:

auto toImpl(T, S, bool fq = false)(auto ref E e)
if (is(S == enum) && is(T==string))
{}

with "fq" a CT bool that indicates if the output includes the "enum
identifier".
"Fully qualified" would mean that even the module name would be included so I
suppose that what you want is actually the enum identifier.



By the way why do you report this as a dmd (and not phobos) issue ?

--

[Issue 16189] Optimizer bug, with simple test case

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com
 OS|Windows |All

--- Comment #1 from ag0ae...@gmail.com ---
Slightly more reduced:


void main()
{
ubyte[9][1] data;
size_t a = 0;
loop:
data[0] = data[a];
a--;
bool b = false;
if (b) goto loop;
assert(a == -1); // Fails with -O
}


Also happens on Linux.

--

[Issue 16188] [REG2.069] ICE on invalid code

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
Summary|ICE on invalid code |[REG2.069] ICE on invalid
   ||code

--- Comment #1 from ag0ae...@gmail.com ---
Reduced further:


void where() { Where().name; }

struct Where
{
void opDispatch(string name)()
{
alias FieldType = typeof(getMember);
WhereField!FieldType;
}
}

struct WhereField(FieldType) {}


Doesn't segfault with 2.068.2 and earlier.

--

to!string on enum should be fully qualified for consistency

[Timothee Cour via Digitalmars-d]

What's the rationale for to!string not being fully qualified? it breaks
reconstructing a struct from it's to!string representation whenever the
struct contains an enum somewhere.

What's a workaround?

filed as https://issues.dlang.org/show_bug.cgi?id=16190

[Issue 16190] New: to!string on enum should be fully qualified for consistency

[via Digitalmars-d-bugs]

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

  Issue ID: 16190
   Summary: to!string on enum should be fully qualified for
consistency
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

enum A{
  a1,
  a2,
}

struct B{
  A b1;
  string b2;
  int c3;
}

import std.conv:to;

void main(){
  auto b=B(A.a1, "foo", 13);
  enum b_string=`B(a1, "foo", 13)`;
  assert(b.to!string == b_string);
  mixin(`auto b1=B(A.a1, "foo", 13);`);//works
  //mixin(`auto b2=`~b_string~`;`);//Error: undefined identifier 'a1'
}

Pretty much every type in D works when reconstructing as I did above:
mixin(`auto b2=`~b.to!string~`;`);
except when there's an enum type somewhere inside

What's a workaround?

--

[Issue 13572] etc.c.zlib must be nothrow

[via Digitalmars-d-bugs]

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

--- Comment #4 from Ketmar Dark  ---
(In reply to Steven Schveighoffer from comment #2)
> PR does not mark everything @trusted, that is not a good idea. So that part
> is WONTFIX. nothrow is correct.

i'd prefer it to have `@trusted` too, but... ok, it's not an issue, i can mark
my wrappers `@trusted` instead. thanks. ;-)

--

Re: problem using ldc 1.0.0 as D compiler

[yawniek via Digitalmars-d]

On Tuesday, 21 June 2016 at 16:26:14 UTC, Satoshi wrote:

On Monday, 20 June 2016 at 11:28:58 UTC, Antonio Corbi wrote:

Hi folks!

I'm using ldc version:
LDC - the LLVM D compiler (1.0.0):
  based on DMD v2.070.2 and LLVM 3.8.0
  built with DMD64 D Compiler v2.071.0
  Default target: x86_64-unknown-linux-gnu
  Host CPU: core2

[...]


I have the same problem with LDC 1.1.0 on Arch Linux


you could use ldc-git from aur,
https://aur.archlinux.org/packages/ldc-git/
this has static phobos

[Issue 13572] etc.c.zlib must be nothrow

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/0ae7812969c5d763b0cf133e75dd488845a93ca4
Fix Issue 13572: etc.c.zlib must be nothrow

https://github.com/dlang/phobos/commit/968329fc75fffc5e96f0ac108921bfa011d8407a
Merge pull request #4451 from JackStouffer/patch-10

Fix Issue 13572: etc.c.zlib must be nothrow

--

Re: Meaning of const variables

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

On Tue, Jun 21, 2016 at 01:48:27PM +, jmh530 via Digitalmars-d-learn wrote:
[...]
> Thanks to you and the others for the detailed clarifications. I think
> part of the difficulty is that there are basically three things being
> discussed that are all very similar: an alias to data, a pointer to
> data, and a view of data.

The word "alias" is unfortunately overloaded to mean similar, but not
exactly the same, things.

"Alias" as used in the keyword "alias" is a compiler construct that has
no real bearing on the type system.  All it is, is to create a new name
for something. For example, if I have:

struct S {
int x;
}
alias y = S.x;

all this means is that whenever the compiler sees "y" it should act as
if it has seen "S.x" instead. Well, not exactly, but basically y will
refer to whatever S.x refers to in the scope of the declaration.  This
makes it useful sometimes for naming things that are hard or impossible
to name in a different scope, for example:

struct S(T) {
alias ElementType = T;
}
S!int s;
static assert(is(s.ElementType == int));

>From an outsider's POV, the template parameter T is not easily obtained,
but having a convenient alias inside the scope where it *is* easily
obtained, makes it readily available to outside code.

None of this is related to the present topic, though.  Which brings us
to the second meaning of "alias", as used in the type system to mean
that the same data can be reached from multiple references.  At the
bottom of this is pointers, and abstractions built on top of pointers.

int x;
int* p = 

This sense of "alias" is usually used as a verb, as in "the pointer p
aliases the variable x". Meaning, you can reach the data represented by
x via the pointer p.  So this is similar to the first meaning of "alias"
in the sense that p is kinda like a different name for x, but
semantically it's not quite the same thing, because alias in the first
sense is a compile-time concept of having one identifier being treated
as though it were another, whereas alias in the second sense here is a
runtime concept, in that the data x exists somewhere in memory, say
location L, and the pointer p happens to contain the value L, so using p
we can find x in memory without actually referring to x directly in the
code.

Now, what's the distinction between int*, const(int)*, and
immutable(int)*?  Or, for that matter, const(int*) and immutable(int*)?

To understand this, it's useful to think of the data being pointed to
distinctly from the pointer.  All of the above pointers point to some
int sitting somewhere in memory.  Let's say there are two ints, sitting
in memory locations L1 and L2, respectively. When we declared the two
ints, we specified the first one as simply 'int', meaning it's mutable.
So memory location L1 contains an int that can be modified.  Let's say
the second int is declared as immutable(int), so L2 contains an int
that, once initialized, cannot be modified.  (In this respect, there is
no difference if we declared const(int) instead, since either way nobody
can modify the value once it's initialized.)

Now, int* is a pointer to (mutable) int, so it can never point to L2. If
the language allowed that, it would break the contract that L2 cannot be
modified. Similarly, immutable(int)* is a pointer to immutable(int), so
it can never point to L1.  However, const(int)* can point to both L1 and
L2, because const(int)* just means that you cannot use *this* pointer to
modify the data, but somebody else who has a mutable reference (i.e.,
int*) pointing to the same data, may use it to modify the data.

So in short:

int*means "pointer to an int that anybody can modify"
immutable(int)* means "pointer to an int that nobody can modify"
const(int)* means "pointer that cannot be used to modify the int,
but can be used to read the int"

So if you have an int* in hand, you know that the memory location it
points to is mutable, and if you have an immutable(int)* in hand, you
know that the memory location it points to is immutable (to everybody,
not just you).  However, if you have a const(int)* in hand, all you know
is that *you* can't modify the data (or more precisely, you cannot use
this particular pointer to modify the data), but it says nothing about
whether the data itself is actually modifiable or not.

What about const(int*) and immutable(int*)?  Here, thanks to transitive
const in D, the const and immutable applies both to the pointer and the
data pointed to. So const(int*) means that the data cannot be modified
through this pointer, and also that you cannot modify this pointer
itself.  (But somebody with a mutable reference to this pointer may
change what it points to.) Similarly, immutable(int*) means that the
data cannot be modified by anybody (whether through this pointer or
otherwise), and the pointer itself also cannot be modified by anybody.


T

Re: More suggestions for find()

[Wyatt via Digitalmars-d]

On Monday, 20 June 2016 at 16:09:21 UTC, qznc wrote:

We cannot port it directly since it is GPL code.


Would it work to port from Musl instead?

-Wyatt

Re: problem using ldc 1.0.0 as D compiler

[Satoshi via Digitalmars-d]

On Monday, 20 June 2016 at 11:28:58 UTC, Antonio Corbi wrote:

Hi folks!

I'm using ldc version:
LDC - the LLVM D compiler (1.0.0):
  based on DMD v2.070.2 and LLVM 3.8.0
  built with DMD64 D Compiler v2.071.0
  Default target: x86_64-unknown-linux-gnu
  Host CPU: core2

[...]


I have the same problem with LDC 1.1.0 on Arch Linux

Re: Fiber implementation questions

[Steven Schveighoffer via Digitalmars-d]

On 6/21/16 11:43 AM, Dicebot wrote:

On Tuesday, 21 June 2016 at 12:18:37 UTC, Steven Schveighoffer wrote:

On 6/21/16 6:14 AM, Dicebot wrote:

On 06/20/2016 11:17 PM, deadalnix wrote:

Q2: core.thread.Fiber implementation looks like GC does not scan
function stacks for yielded contexts. Why?



Doesn't it ?


https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4328
allocates fiber stack using mmap / malloc / VirtualAlloc and doesn't
seem to register that memory in GC. But that may be indirect result of
https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4439
call, which is why I am not sure.


It appears that Fibers interact with the GC differently:

https://github.com/dlang/druntime/blob/master/src/core/thread.d#L1611



I suspected something like this, it explains a lot. Do you know why this
approach was chosen instead of simply registering allocated memory for
GC scan? Does GC has special approach for stack scanning which differs
from normal memory?


There must be a reason, I think maybe Martin or Sean would know more.

-Steve

[Issue 13572] etc.c.zlib must be nothrow

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #2 from Steven Schveighoffer  ---
PR does not mark everything @trusted, that is not a good idea. So that part is
WONTFIX. nothrow is correct.

--

Re: Meaning of const variables

[jmh530 via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 15:21:01 UTC, Ali Çehreli wrote:

[snip]


Thanks.

Re: Phobos: __FILE__ as template default parameter

[ZombineDev via Digitalmars-d]

On Tuesday, 21 June 2016 at 10:34:01 UTC, pineapple wrote:

On Tuesday, 21 June 2016 at 10:28:03 UTC, pineapple wrote:

On Tuesday, 21 June 2016 at 02:59:44 UTC, ZombineDev wrote:

I think it would be good idea to take this even further:

T4 foo(T4, T0, T1, Ts..., T2, T3)(T0 t0, T1 t1, Args args, T2 
t2, T3 t3)


In other words, I think that the limitation that variadic 
template parameter list must be at the end of the function 
parameters is arbitrary and just a deficiency of the current 
implementation.


I don't disagree with you, but this is a separate issue. If 
the arguments trailing Args have default values (as they would 
in the case of __FILE__, __LINE__) it will create ambiguity.


void foo(Args...)(Args args, int n = 1);

What happens if I do this? foo(1, 2, 3, 4); Is n 1 or 4?


Another thought: What if in this case the trailing arguments 
are always the default value? In this case n is /always/ 1, 
file and line would always be __FILE__ and __LINE__. This would 
be a more general solution and maybe not too intolerably ugly.


It should work just like the regular expression .*.? - if all 
parameters after the variadic list have default values, then the 
list should capture all arguments and the last parameters use 
their default values. E.g. args is (1, 2, 3, 4) and n is 1 in 
your example.
In general the strategy should be: the variadic list captures as 
much arguments as its constraints allow it to capture.


// regex: (\d*)(.)(.?)
// (pretend that \d means scalar type)
void foo(T1, T2, Args...)(Args args, T1 t1, T2 t2 = "default"w)
if (allSatisfy!(isScalarType, Args))
{
pragma (msg, Args, ", ", T1, ", ", T2);
}

foo(0, 0L, "asd");   // (int, long), string, wstring
foo("asd", "sdf");   // (), string, string
foo('c', new Object, 3); // (char), Object, int

Re: Fiber implementation questions

[Dicebot via Digitalmars-d]

On Tuesday, 21 June 2016 at 12:18:37 UTC, Steven Schveighoffer 
wrote:

On 6/21/16 6:14 AM, Dicebot wrote:

On 06/20/2016 11:17 PM, deadalnix wrote:
Q2: core.thread.Fiber implementation looks like GC does not 
scan

function stacks for yielded contexts. Why?



Doesn't it ?


https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4328
allocates fiber stack using mmap / malloc / VirtualAlloc and 
doesn't
seem to register that memory in GC. But that may be indirect 
result of

https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4439
call, which is why I am not sure.


It appears that Fibers interact with the GC differently:

https://github.com/dlang/druntime/blob/master/src/core/thread.d#L1611

-Steve


I suspected something like this, it explains a lot. Do you know 
why this approach was chosen instead of simply registering 
allocated memory for GC scan? Does GC has special approach for 
stack scanning which differs from normal memory?

Re: D casting broke?

[Joerg Joergonson via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 02:39:25 UTC, H. S. Teoh wrote:
On Tue, Jun 21, 2016 at 02:09:50AM +, Joerg Joergonson via 
Digitalmars-d-learn wrote: [...]
Lets suppose A -> B means B is derived from A. That is, any 
object of B can be cast to A because the memory layout of A is 
contained in B and any object of B can be accessed as if it 
were an A.


Correct.


Template parameters also can have this property since they are 
types.

[...]

The template *parameters* can also have this property. But the 
*template* itself may not.  Contrived example:


class A { int x; }
class B : A { int y; }

struct Templ(C : class) {
int[C.sizeof] data;
}

Templ!A a;
Templ!B b;

a = b; // should this be allowed?

It should be clear that allowing this would cause problems, 
because in spite of the relationship between A and B, and hence 
the relationship between the template arguments of a and b, the 
same relationship does not hold between Templ!A and Templ!B 
(note that .data is an array of ints, not ubytes, and may not 
contain data in any layout that has any corresponds with the 
relationship between A and B).


Another contrived example:

class A { int x; }
class B : A { int y; }

struct Templ(C : class) {
static if (C.sizeof > 4) {
string x;
} else {
float y;
}
}

Allowing implicit casting from Templ!B to Templ!A would not 
make sense, because even though the respective template 
arguments have an inheritance relationship, the Templ 
instantiation made from these classes has a completely 
unrelated and incompatible implementation.




Well, I never mentioned any implicit casting. Obviously explicit 
casting wouldn't make sense either. It is a good example as it 
can show that Templ!A is completely different than Templ!B and no 
conversion is every possible even if A and B are related.


But I still think these are different examples.

You are talking about A!a vs A!b while I am talking about A!a vs 
B!b. I believe, but could be mistaken, that there is a subtle 
difference. I know it seems like B!b can be reduced to A!b, and 
the type system allows this... but if it never happens then all 
these cases explaining the problem of going from A!b to A!a are 
moot.


Now granted, these are contrived examples, and in real-life we 
may not have any real application that requires such strange 
code. However, the language itself allows such constructs, and 
therefore the compiler cannot blindly assume any relationship 
between Templ!A and Templ!B even though there is a clear 
relationship between A and B themselves.


I agree. I am not asking for blind assumptions. When I inform the 
compiler I want to cast to an object that I know should 
succeed(it was designed to do so) I don't expect a null. (As has 
been mentioned, I can do this using the void* trick, so there is 
a way)


What should be done if we wish to allow converting Templ!B to 
Templ!A, though?  One way (though this still does not allow 
implicit casting) is to use opCast:


struct Templ(C : class) {
... // implementation here

auto opCast(D : class)
if (is(C : D)) // C must be a base class of D
{
...
// do something here to make the conversion
// valid. Maybe something as simple as:
return cast(Templ!D) this;

// (provided that there are no memory layout
// problems in Templ's implementation, of
// course).
}
}

Implementing this using opCast actually gives us an even more 
powerful tool: provided it is actually possible to convert 
between potentially incompatible binary layouts of Templ!A and 
Templ!B, the opCast method can be written in such a way as to 
construct Templ!A from Templ!B in a consistent way, e.g., by 
treating B as a subclass of A and calling the ctor of Templ!A, 
or, in the case of my contrived examples, do something 
non-trivial with the .data member so that the returned Templ!A 
makes sense for whatever purpose it's designed for.  It allows 
the implementor of the template to specify exactly how to 
convert between the two types when the compiler can't possibly 
divine this on its own.




While this is nice, the problem was how to convert. Even in 
opCast I would get a null and I wouldn't want to reconstruct A!a 
from B!b because that would essentially entail duplication. Of 
course, now I know I can just cast to void* then back and 
essentially trick/bypass the compilers type system checking.


This is kind of bringing a nuclear warhead to an anthill, 
though.  In my own code where I have a template wrapping around 
types that need to convert to a common base type, I find it 

Re: Meaning of const variables

[Ali Çehreli via Digitalmars-d-learn]

On 06/21/2016 06:48 AM, jmh530 wrote:

> So an immutable pointer guarantees that whatever it is pointing to will
> never change,

Yes but saying "_requires_ that data never changes" is more correct. 
When it comes to a pointer (i.e. the user of data), "guarantee" is 
related to const.


> but a const pointer can also point to mutable data, which
> might change some other way.

Yes, const means "_I_ will not change."

const and immutable are not interesting unless there are references. 
Otherwise, who cares whether data was copied from const or immutable?


const c = 42;
immutable i = 43;

int a = c;
int b = i;

a and b are copied from const and immutable, respectively, but we don't 
care. (Except when they have members or members of members that are 
references.)


const and immutable are interesting when there are references, of which, 
function parameters make the issue clear to me:


void foo(ref const int c, ref immutable int i) {
// ...
}

foo says "I guarantee that I will not modify your data, which I'm 
referring to as c" and "I require that nobody will modify your data, 
which I'm referring to as i". So, the const-immutable distinction of a 
reference parameter is what makes it easy to understand to me.


As I observe in that chapter[1] and later in the book[2], it's not 
always clear which one to use. For example, although const seems more 
usable, the fact that it has to work with mutable and immutable 
necessarily "erases" the actual mutability[1].


Another example is with constructor parameters where immutable is 
potentially faster[2]. That chapter does not really explain why so here 
is an example:


struct S {
string fileName;// Needs immutable

// Takes as const reference, presumably to be more useful
this(const char[] fileName) {
// Since const does not guarantee immutability, must take a copy
import std.conv;
this.fileName = fileName.to!string;
}
}

void main() {
// The copy in the constructor is unnecessary in this case because here
// the string is already immutable. S's constructor could not know 
that so

// it had to take a copy.
auto s = S("my_file");
}

The same issue applies for other functions where a reference needs to be 
kept longer for later use.


Ali

[1] 
http://ddili.org/ders/d.en/const_and_immutable.html#ix_const_and_immutable.parameter,%20const%20vs.%20immutable


[2] http://ddili.org/ders/d.en/special_functions.html
(Search for the section "Immutability of constructor parameters".)

[Issue 16189] Optimizer bug, with simple test case

[via Digitalmars-d-bugs]

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

Kirill Kryukov  changed:

   What|Removed |Added

 CC||kkryu...@gmail.com

--

[Issue 16189] New: Optimizer bug, with simple test case

[via Digitalmars-d-bugs]

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

  Issue ID: 16189
   Summary: Optimizer bug, with simple test case
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kkryu...@gmail.com

Consider this code:
=== a.d ===
struct T { long a, b; }
T[] data = [{0,0}];
void main()
{
int a = 0;
for (int i = 0; i >= 0; i--)
{
data[0] = data[a];
a--;
}
assert(a == -1); // Fails with -O
}
=== end ===

Fails when built with "-O", succeeds without "-O". The full command line:
dmd a.d -ofa.exe -O
dmd a.d -ofb.exe

Windows 7, dmd 2.071.0

If you add "-m64" to dmd command, the bug disappears, but re-appears if "int a"
is changed to "long a".

Reduced from a large project with the help of dustmite and a lot of "WTF!".

--

Re: Examples of dub use needed

[Guido via Digitalmars-d]

On Tuesday, 21 June 2016 at 08:58:59 UTC, Dicebot wrote:

On 06/21/2016 10:24 AM, poliklosio wrote:

Wow, really?
Then what is the fetch command for? I started using dub a 
recently (2
months ago) and totally didn't notice that there is any other 
purpose of
the fetch command. I even installed dcd, dfmt and dscanner 
through dub
fetch, only to find out these were older versions which didn't 
work.

So what is the purpose of dub fetch?


Apart from `--cache=local` version, one of intended use case is 
to get various small utility tools needed only during 
development and not needing to be distributed to the end user, 
like dfmt. After `dub fetch dfmt` one can run `dub run dfmt 
` to invoke such tool without knowing where dub cache is 
located.


But it is indeed supposed to be rare case and I do recommend to 
install such tools via system package manager instead whenever 
possible. So yes, you don't need `dub fetch` at all for most 
part.


Thanks for the replies. This really clears things up.

I'm the sort of person who learns by example, and what I was 
saying is that there aren't enough examples online of how dub is 
used in a practical setting.


I'm also the sort of person who doesn't trust toolchains that 
need to download things every time from the internet just to 
compile. Is this what dub is doing? In other words, when a 
project is built using dub, does it use the local cache from the 
last build by default, check for later versions, pull things from 
the internet, etc? Or do I need -cache=local for that?

Re: Examples of dub use needed

[jmh530 via Digitalmars-d]

On Tuesday, 21 June 2016 at 04:42:39 UTC, Guido wrote:


It deserves a bigger mention in the meager documentation.



IMHO, Dub 1.0 should have done a bit more work on the 
documentation.

Re: Meaning of const variables

[jmh530 via Digitalmars-d-learn]

On Tuesday, 21 June 2016 at 02:54:06 UTC, ketmar wrote:




Thanks to you and the others for the detailed clarifications. I 
think part of the difficulty is that there are basically three 
things being discussed that are all very similar: an alias to 
data, a pointer to data, and a view of data.




so, what that quote essentially means is: "`const` pointers can 
point to mutable data, but `immutable` pointers cannot".




So an immutable pointer guarantees that whatever it is pointing 
to will never change, but a const pointer can also point to 
mutable data, which might change some other way.

Re: D-Man culture

[Ryuichi OHORI via Digitalmars-d-announce]

On Monday, 20 June 2016 at 01:40:58 UTC, H. S. Teoh wrote:
On Sun, Jun 19, 2016 at 03:01:33PM +, Seb via 
Digitalmars-d-announce wrote:

Hi,

I am not sure how much you have heard about the D-Man, but in 
Japan

there is an entire culture based on the D-Man!
As I learned about this by accident (and even Walter didn't 
know about
it), I thought I share this great movement with the DLang 
community!

[...]

I also made a 3D PovRay model of D-Man some years ago. Here's a 
sample render showing four poses:


http://eusebeia.dyndns.org/~hsteoh/tmp/mascot.png

If anyone's interested in playing around with the model, I can 
put the PovRay source files up somewhere.



T


@simd_nyan has even made 3D-printed D-manavailable to everyone!
http://make.dmm.com/item/437376/
But only domestic shipping... :(

[Issue 13572] etc.c.zlib must be nothrow

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Jack Stouffer  ---
https://github.com/dlang/phobos/pull/4451

--

Re: Is there anyway to make opApply @nogc?

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

On Tuesday, 21 June 2016 at 12:48:04 UTC, Gary Willoughby wrote:
I have no idea what that means. Can anyone shed more light on 
this, please?


So when you use local variables in a delegate, the compiler 
usually makes a copy of them just in case the delegate gets saved 
for later.


When you mark it scope, you promise that you won't save it for 
later, so the compiler skips making the copy.

Re: Is there anyway to make opApply @nogc?

[Gary Willoughby via Digitalmars-d-learn]

On Monday, 20 June 2016 at 15:27:32 UTC, Adam D. Ruppe wrote:

On Monday, 20 June 2016 at 15:13:53 UTC, Gary Willoughby wrote:
I think the problem is that the delegate which is required by 
opApply is allocated using the GC.


make the delegate in opApply scope

int opApply(scope int delegate(whatever) dg)


I'm still not sure what this achieves. The description on the 
stackoverflow question reads: "And when the compiler sees this on 
delegates, it will avoid allocating a closure when taking the 
address of a local function. This is essential in opApply loops."


I have no idea what that means. Can anyone shed more light on 
this, please?

Re: Fiber implementation questions

[Steven Schveighoffer via Digitalmars-d]

On 6/21/16 6:14 AM, Dicebot wrote:

On 06/20/2016 11:17 PM, deadalnix wrote:

Q2: core.thread.Fiber implementation looks like GC does not scan
function stacks for yielded contexts. Why?



Doesn't it ?


https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4328
allocates fiber stack using mmap / malloc / VirtualAlloc and doesn't
seem to register that memory in GC. But that may be indirect result of
https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4439
call, which is why I am not sure.


It appears that Fibers interact with the GC differently:

https://github.com/dlang/druntime/blob/master/src/core/thread.d#L1611

-Steve

Re: D casting broke?

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/20/16 10:45 PM, Joerg Joergonson wrote:

On Monday, 20 June 2016 at 23:35:28 UTC, Steven Schveighoffer wrote:

On 6/19/16 5:19 PM, Joerg Joergonson wrote:

On Sunday, 19 June 2016 at 20:21:35 UTC, ag0aep6g wrote:

On 06/19/2016 09:59 PM, Joerg Joergonson wrote:

This should be completely valid since B!T' obviously derives from A!T
directly


ok


and we see that T' derives from b which derives from a
directly.


ok


So B!b is an entirely derived from A!a


No. B!b is derived from A!b, not from A!a. `b` being derived from `a`
does not make A!b derived from A!a.


why not? This doesn't seem logical!


Because:

class A(T : a)
{
  static if(is(T == a))
 int oops;
  ...
}

Now A!b and A!a have different layouts. They cannot be related, even
if the template arguments are related. I could introduce another
virtual function inside the static if, same result -- vtable is messed
up.

In general, an instantiation of a template aggregate (class or struct)
is not castable implicitly to another instantiation of the same
aggregate unless explicitly declared.

And note that D does not allow multiple inheritance. I don't think you
can solve this problem in D.



Yes, but all you guys are doing is leaving out what I'm actually doing
and creating a different problem that may not have the same issues.


We're not "creating" any different problems. The compiler has to assume 
the worst, especially when it must make assumptions at runtime. The same 
template instantiated with different parameters is different, not 
related. In order for it to be related, you have to declare that somehow.


-Steve

Re: vibe.d - asynchronously wait() for process to exit

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/20/16 11:01 PM, Vladimir Panteleev wrote:

On Monday, 20 June 2016 at 19:39:42 UTC, Steven Schveighoffer wrote:

On 6/20/16 12:29 PM, Vladimir Panteleev wrote:

On Monday, 20 June 2016 at 16:16:32 UTC, Steven Schveighoffer wrote:

What is the OS support for waitid
(http://man7.org/linux/man-pages/man2/waitpid.2.html)? Seems to have
support for async waiting of multiple processes (at least it can
return immediately if no child has exited). One consideration is how
responsive you need to be to a process exiting -- is it ok for example
to be notified 500ms after the process exits? If so, you can
interleave timed waits for socket data with a check to see if any
process exits. I've done this in the past for such things. I don't
know how well this works for libevent though.


std.process has tryWait() if polling were acceptable, but I would really
like to avoid it. Or have I misunderstood?


tryWait works on a single PID. From my reading of the docs, it appears
you can call waitid and no matter how many children you have, if one
exits, then it will capture that.


Ah, OK. But then so does SIGCHLD, asynchronously.


But not where you need it to be handled :) This is the reason for the 
"self pipe trick" that you use.


I'll note that waitid actually isn't needed, you can do waitpid(-1, ...) 
and it waits for any process. I didn't realize that before.



It would be nice if the Linux wait mechanisms were all standardized
similar to Windows. I think the only thing that allows such universal
access is file descriptors. Processes are definitely a case where it's
not easy to deal with the events. Signal handlers suck as an async
mechanism.


It's really not that hard. It's just that no one bothered to implement
this correctly in Vibe. Process or signal handling does not seem to be a
Vibe.d driver primitive.

Signals interrupt blocking calls such as select/poll. Even if you don't
have a signal handler registered, you could in theory call tryWait or
similar on every process ID you're waiting on in an event loop idle
handler. It's not very efficient, of course, and degrades poorly as the
number of processes and events grows.


Only if you handle the signal in that thread.



You can also register a signal handler, and just ping a socket pair
(unmanaged on one side, managed by the event loop on the other). This is
what I do in ae.


Yeah, probably the right thing to do is a signal handler that reaps all 
terminated processes, putting the data into the pipe/socket.



As I recently learned, there's also signalfd. With that, had Vibe.d had
a primitive to wrap a file descriptor into a stream it can manage, it
would be as simple as reading from it. But it doesn't seem to have one
so I guess you need to use createFileDescriptorEvent and the raw C
read() function.


Hm... I hadn't heard of this. Some seem to think that creates its own 
problems, but I don't know if SIGCHLD is one of them since that's 
blocked by default: https://ldpreload.com/blog/signalfd-is-useless



But my point was that you can poll on every start of event loop, and
handle process exits if they are ready, and then every 500ms or so if
no i/o becomes ready. In practice, this should be pretty responsive,
unless you are only doing process execution and no i/o. And half
second delay between process exit and handling of result is pretty
small even in that case.


Sure, but to be honest that's nothing but an ugly hack. :) Even if not
for the 500ms delay - every bit adds up, and timers are much worse than
event handling on e.g. mobile devices than servers, because they incur a
CPU wake-up and then end up doing nothing most of the time.


What are you doing spawning child processes on a mobile device? :)

-Steve

Re: vibe.d - asynchronously wait() for process to exit

[Johannes Pfau via Digitalmars-d-learn]

Am Tue, 21 Jun 2016 03:01:39 +
schrieb Vladimir Panteleev :

> 
> As I recently learned, there's also signalfd. With that, had 
> Vibe.d had a primitive to wrap a file descriptor into a stream it 
> can manage, it would be as simple as reading from it. But it 
> doesn't seem to have one so I guess you need to use 
> createFileDescriptorEvent and the raw C read() function.

Such a wrapper would be useful for some more things (inotify/fanotify).
Anyway, I wrote such a similar wrapper for a serial port module:
https://github.com/jpf91/vibe-serial/blob/master/src/vibe/serial.d#L145

Only reading is fully implemented / tested, but maybe this is still
useful. This vibe.d issue could cause problems though:

https://github.com/rejectedsoftware/vibe.d/issues/695

[Issue 15704] @safe code should not allow copying to/from void[]

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/378e6e3ff01e8e1afd5b5bb97d259ae68918ef9e
fix Issue 15704 - @safe code should not allow copying to/from void[]

https://github.com/dlang/dmd/commit/8ed696695c913234d7bed276215c9dcae8a9cc66
Merge pull request #5877 from WalterBright/fix15704

fix Issue 15704 - @safe code should not allow copying to/from void[]

--

[Issue 15704] @safe code should not allow copying to/from void[]

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Release DUB 1.0.0

[Saurabh Das via Digitalmars-d-announce]

On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote:
I'm pleased to announce the release of the first stable version 
of the DUB package manager. Stable in this case means that the 
API, the command line interface and the package recipe format 
will only receive fully backwards compatible changes and 
additions for a while.


[...]


Congratulations on v1.0.0 and thank you for making and 
maintaining DUB! :)


Saurabh

Re: Phobos: __FILE__ as template default parameter

[David Nadlinger via Digitalmars-d]

On Monday, 20 June 2016 at 08:10:19 UTC, Dicebot wrote:
How about defining semantics like "try inlining if possible, 
fallback to always emitting symbol to object file otherwise"? 
That would also allow compatible implementation in dmd.


This would get rid of the undefined symbols, but there is a much 
more subtle problem here that nobody has brought up yet: If the 
template ends up being emitted twice with different mangled 
names, then, well, it ends up existing twice in the final 
executable.


This is not really an issue for functions, but very much so for 
data symbols (e.g. a static variable inside a function), where 
you could end up with the same alias referring to two different 
pieces of data depending on where it is used from.


The root of this issue is that __FILE__ introduces incidental 
environmental state into the otherwise pure module system.


 — David

[Issue 16188] ICE on invalid code

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

URL|http://dlang.org/   |
 CC||greensunn...@gmail.com
Summary|[Home]  |ICE on invalid code

--

Re: Phobos: __FILE__ as template default parameter

[pineapple via Digitalmars-d]

On Tuesday, 21 June 2016 at 10:28:03 UTC, pineapple wrote:

On Tuesday, 21 June 2016 at 02:59:44 UTC, ZombineDev wrote:

I think it would be good idea to take this even further:

T4 foo(T4, T0, T1, Ts..., T2, T3)(T0 t0, T1 t1, Args args, T2 
t2, T3 t3)


In other words, I think that the limitation that variadic 
template parameter list must be at the end of the function 
parameters is arbitrary and just a deficiency of the current 
implementation.


I don't disagree with you, but this is a separate issue. If the 
arguments trailing Args have default values (as they would in 
the case of __FILE__, __LINE__) it will create ambiguity.


void foo(Args...)(Args args, int n = 1);

What happens if I do this? foo(1, 2, 3, 4); Is n 1 or 4?


Another thought: What if in this case the trailing arguments are 
always the default value? In this case n is /always/ 1, file and 
line would always be __FILE__ and __LINE__. This would be a more 
general solution and maybe not too intolerably ugly.

Re: Phobos: __FILE__ as template default parameter

[pineapple via Digitalmars-d]

On Tuesday, 21 June 2016 at 02:59:44 UTC, ZombineDev wrote:

I think it would be good idea to take this even further:

T4 foo(T4, T0, T1, Ts..., T2, T3)(T0 t0, T1 t1, Args args, T2 
t2, T3 t3)


In other words, I think that the limitation that variadic 
template parameter list must be at the end of the function 
parameters is arbitrary and just a deficiency of the current 
implementation.


I don't disagree with you, but this is a separate issue. If the 
arguments trailing Args have default values (as they would in the 
case of __FILE__, __LINE__) it will create ambiguity.


void foo(Args...)(Args args, int n = 1);

What happens if I do this? foo(1, 2, 3, 4); Is n 1 or 4?

Re: Fiber implementation questions

[Dicebot via Digitalmars-d]

On 06/20/2016 11:17 PM, deadalnix wrote:
>> Q2: core.thread.Fiber implementation looks like GC does not scan
>> function stacks for yielded contexts. Why?
>>
> 
> Doesn't it ?

https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4328
allocates fiber stack using mmap / malloc / VirtualAlloc and doesn't
seem to register that memory in GC. But that may be indirect result of
https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4439
call, which is why I am not sure.

[Issue 16188] [Home]

[via Digitalmars-d-bugs]

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

Sobirari Muhomori  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--

Re: Need DMD AST expertise

[Guillaume Chatelet via Digitalmars-d]

On Tuesday, 21 June 2016 at 09:13:26 UTC, Jacob Carlborg wrote:

On 2016-06-21 09:45, Guillaume Chatelet wrote:


AFAIK basic types are instantiated once and reused:
https://github.com/dlang/dmd/blob/b67694a0d74437d3a1581da2b9f1b785dc7b3c88/src/mtype.d#L861


So comparing pointers wouldn't work.


Yeah. I'm just guessing here :). Sorry, I don't think I can 
help you.


Thx anyways! I'll continue my journey [1] :)

1. https://cdn.meme.am/instances/39916320.jpg

Re: Need DMD AST expertise

[Jacob Carlborg via Digitalmars-d]

On 2016-06-21 09:45, Guillaume Chatelet wrote:


AFAIK basic types are instantiated once and reused:
https://github.com/dlang/dmd/blob/b67694a0d74437d3a1581da2b9f1b785dc7b3c88/src/mtype.d#L861


So comparing pointers wouldn't work.


Yeah. I'm just guessing here :). Sorry, I don't think I can help you.

--
/Jacob Carlborg

Re: Release DUB 1.0.0

[wobbles via Digitalmars-d-announce]

On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote:
I'm pleased to announce the release of the first stable version 
of the DUB package manager. Stable in this case means that the 
API, the command line interface and the package recipe format 
will only receive fully backwards compatible changes and 
additions for a while.


[...]


Congrats - this is great stuff!

Re: Examples of dub use needed

[Sönke Ludwig via Digitalmars-d]

Am 21.06.2016 um 06:42 schrieb Guido:

Dub doesn't really work like other package managers. When I load a package:

dub fetch scriptlike

It stores it someplace and doesn't say where. You have to run 'dub list'
to figure out where. That's is very different than other packages. It
deserves a bigger mention in the meager documentation.

I've been trying to init a project using the command

dub -init -f sdl trickproject
-or-
dub -f sdl -init trickproject


It must be "dub init -f sdl", without the dash in front of "init". 
Otherwise it looks correct.




and nothing seems to parse.

So, I look at the source code for the format option and see this:
args.getopt("f|format", _format, [
 "Sets the format to use for the package description file. Possible
values:",
 "  " ~ [__traits(allMembers, PackageFormat)].map!(f => f ==
m_format.init.to!string ? f ~ " (default)" : f).join(", ")
]);

It doesn't look straightforward at all. Not sure why there is so much
complexity on this particular commandline option, but shouldn't these
command options work the way I have them?


The complexity just comes from dynamically determining the default file 
format (to avoid it getting out of sync).

Re: Examples of dub use needed

[Dicebot via Digitalmars-d]

On 06/21/2016 10:24 AM, poliklosio wrote:
> Wow, really?
> Then what is the fetch command for? I started using dub a recently (2
> months ago) and totally didn't notice that there is any other purpose of
> the fetch command. I even installed dcd, dfmt and dscanner through dub
> fetch, only to find out these were older versions which didn't work.
> So what is the purpose of dub fetch?

Apart from `--cache=local` version, one of intended use case is to get
various small utility tools needed only during development and not
needing to be distributed to the end user, like dfmt. After `dub fetch
dfmt` one can run `dub run dfmt ` to invoke such tool without
knowing where dub cache is located.

But it is indeed supposed to be rare case and I do recommend to install
such tools via system package manager instead whenever possible. So yes,
you don't need `dub fetch` at all for most part.

Re: Examples of dub use needed

[Mike Parker via Digitalmars-d]

On Tuesday, 21 June 2016 at 07:44:14 UTC, Mike Parker wrote:

global cache. And if you checkout from git directly, you'd have 
to modify the DUB configuration of any projects you want to 
make use of your changes so that they use paths for their 
dependencies rather than versions. dub fetch + dub add-local is 
so much simpler. A


Although, I forgot about dub add-override, which allows you to 
specify a path and version number for a package to be preferred 
over something in the global cache. Using that with git clone 
actually looks to be just as easy as dub fetch/dub add-local, and 
is probably better if you want to submit PRs.

Re: Examples of dub use needed

[Mike Parker via Digitalmars-d]

On Tuesday, 21 June 2016 at 04:42:39 UTC, Guido wrote:
Dub doesn't really work like other package managers. When I 
load a package:


dub fetch scriptlike

It stores it someplace and doesn't say where. You have to run 
'dub list' to figure out where. That's is very different than 
other packages. It deserves a bigger mention in the meager 
documentation.


DUB is not a general-purpose package manager. It's a build tool 
that knows how to manage your package dependencies. Assuming you 
are using DUB to manage a project that uses scriptlike, and you 
have scriptlike configured as a dependency, you do *not* need to 
run dub fetch. When you build your project, DUB will download and 
compile scriptlike for you, make sure its source modules are on 
your import path, and that it is linked with your executable.


In all the years I've used dub, the only time I've cared about 
where its cache is located was when I wanted to zap everything in 
it in one go. By default, on Windows, it's currently the roaming 
appdata directory (though that is likely to change to the local 
appdata dir in a future version), which on Windows 10 is:


C:\Users\User Name\AppData\Roaming\dub

On other systems it should be:

~/.dub

Again, just forget it exists. If you need to worry about 
modifying cached packages or pulling the static libraries out or 
whatever, use dub fetch --cache=local like I described above.

Re: Need DMD AST expertise

[Guillaume Chatelet via Digitalmars-d]

On Tuesday, 21 June 2016 at 06:25:26 UTC, Jacob Carlborg wrote:

On 2016-06-20 22:52, Guillaume Chatelet wrote:


[...]


A guess: "tiargs" is the types of the values passed to the 
template.

"tdtypes" is the types the template is instantiated with.

void foo(T)(T* a);

int b;
foo!(int)(*);

"tiargs" is "int*" and "tdtypes" is "int". But this can easily 
be confirmed using some printf debugging.



[...]


Are the types the same objects so you can compare by just 
comparing the pointers?


AFAIK basic types are instantiated once and reused:
https://github.com/dlang/dmd/blob/b67694a0d74437d3a1581da2b9f1b785dc7b3c88/src/mtype.d#L861

So comparing pointers wouldn't work.

Re: Examples of dub use needed

[Mike Parker via Digitalmars-d]

On Tuesday, 21 June 2016 at 07:24:33 UTC, poliklosio wrote:



Wow, really?
Then what is the fetch command for? I started using dub a 
recently (2 months ago) and totally didn't notice that there is 
any other purpose of the fetch command. I even installed dcd, 
dfmt and dscanner through dub fetch, only to find out these 
were older versions which didn't work.

So what is the purpose of dub fetch?


One use case is to bypass dub's global package cache for specific 
projects. For example, say you're making something using 
DerelictGL3 and DerelictGLFW3, you could do this:


mkdir derelict
cd derelict
dub fetch --cache=local derelict-glfw3 --version=2.0.0
dub fetch --cache=local derelict-gl3 --version=1.0.18
dub fetch --cache=local derelict-util --version=2.0.4

If you need the libraries for a project that isn't using DUB, you 
can then do this:


dub add-local derelict-util-2.0.4
cd derelict-glfw3-2.0.0
dub build -brelease
cd ../derelict-gl3-1.0.18
dub build -brelease
cd ../derelict-util-2.0.4
dub build -brelease

The first line allows derelict-glfw3 and derelict-gl3 to find 
derelict-util when you are building them.


You can use all of the packages with other dub managed projects 
by just using add-local on each of them and not bothering with 
building any of them.


dub add-local derelict-util-2.0.4
dub add-local derelict-glfw3-2.0.0
dub add-local derelict-gl3-1.0.18

DUB will prefer these over the global cache if they are already 
there. This is useful for making changes to the libraries 
yourself and having them show up in other projects that depend on 
them. You certainly don't want to modify the files in the global 
cache. And if you checkout from git directly, you'd have to 
modify the DUB configuration of any projects you want to make use 
of your changes so that they use paths for their dependencies 
rather than versions. dub fetch + dub add-local is so much 
simpler. A

Re: More suggestions for find()

[Guillaume Chatelet via Digitalmars-d]

On Monday, 20 June 2016 at 16:09:21 UTC, qznc wrote:

On Monday, 20 June 2016 at 13:27:59 UTC, Jack Stouffer wrote:

On Monday, 20 June 2016 at 12:34:55 UTC, qznc wrote:

On Sunday, 19 June 2016 at 10:38:27 UTC, qznc wrote:
On Saturday, 18 June 2016 at 18:54:28 UTC, Andrei 
Alexandrescu wrote:

[...]


Compare with memmem. That is 4x faster than the current 
stuff. I guess vector instructions are key. There is a 
branch in my repo.


More like 2x after looking again


Cool :)

What are the chances of getting this in Phobos?


Low.

It requires the GNU libc to link against. We don't want that 
dependency.


We cannot port it directly since it is GPL code.

It is even more of a special case, since it only works for the 
== predicate.


I'm not sure about the vector instructions it requires.

What we need is a clean room implementation of the two way 
string matching algorithm with vector instructions?


Maybe there's some inspiration to get from the source code:
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=string/memmem.c;hb=HEAD
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=string/str-two-way.h;hb=HEAD

Re: Fiber implementation questions

[Ilya Yaroshenko via Digitalmars-d]

On Monday, 20 June 2016 at 20:17:04 UTC, deadalnix wrote:

On Monday, 20 June 2016 at 15:43:27 UTC, Ilya Yaroshenko wrote:
Q2: core.thread.Fiber implementation looks like GC does not 
scan function stacks for yielded contexts. Why?




Doesn't it ?


I thought the code should be added to the GC roots.

Re: Meaning of const variables

[Mike Parker via Digitalmars-d-learn]

behavior is identical. And really, if you never need to take 
the address of the variable, then a manifest constant using 
enum would be more appropriate.




Actually, I should say it *may* be more appropriate. Definitely 
only when the initializer is known at compile time. There are 
cases when you initialize a local immutable variable with a 
runtime value.

Re: Examples of dub use needed

[poliklosio via Digitalmars-d]

On Tuesday, 21 June 2016 at 06:30:11 UTC, Jacob Carlborg wrote:

On 2016-06-21 06:42, Guido wrote:
Dub doesn't really work like other package managers. When I 
load a package:


dub fetch scriptlike

It stores it someplace and doesn't say where. You have to run 
'dub list'
to figure out where. That's is very different than other 
packages. It

deserves a bigger mention in the meager documentation.


Dub doesn't install packages. It's not a tool meant for end 
users. If you want something installed in the traditional sense 
it should go in the system package manager.


Wow, really?
Then what is the fetch command for? I started using dub a 
recently (2 months ago) and totally didn't notice that there is 
any other purpose of the fetch command. I even installed dcd, 
dfmt and dscanner through dub fetch, only to find out these were 
older versions which didn't work.

So what is the purpose of dub fetch?

Re: Release DUB 1.0.0

[Martin Tschierschke via Digitalmars-d-announce]

On Monday, 20 June 2016 at 19:45:29 UTC, Dechcaudron wrote:

On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote:
I'm pleased to announce the release of the first stable 
version of the DUB package manager.


Congratulations and thank you from all of us! DUB is amazing!!!


Me too :-)!

Re: Examples of dub use needed

[Jacob Carlborg via Digitalmars-d]

On 2016-06-21 06:42, Guido wrote:

Dub doesn't really work like other package managers. When I load a package:

dub fetch scriptlike

It stores it someplace and doesn't say where. You have to run 'dub list'
to figure out where. That's is very different than other packages. It
deserves a bigger mention in the meager documentation.


Dub doesn't install packages. It's not a tool meant for end users. If 
you want something installed in the traditional sense it should go in 
the system package manager.



I've been trying to init a project using the command

dub -init -f sdl trickproject
-or-
dub -f sdl -init trickproject

and nothing seems to parse.


The correct way is:

dub init trickproject -f sdl

Note that "init" is a command and not a flag. You can run "dub --help" 
to see the "init" command. The run "dub init --help" to see that help 
for that specific command.


--
/Jacob Carlborg