Error when running vibe.d example application, not sure of the cause.

2016-08-29 Thread e-y-e via Digitalmars-d-learn
I am currently using the following packages on arch linux 
(parabola [1] to be exact):


- DUB version 1.0.0

- LDC version 1.0.0

I create a project with the following command:

$ dub init -t vibe.d vibetest

Change directories:

$ cd vibetest/

And attempt to build and run the project:

$ dub run

However, I get the following output:

Performing "debug" build using ldc2 for x86_64.
vibe-d:utils 0.7.29: building configuration "library"...
vibe-d:data 0.7.29: building configuration "library"...
vibe-d:core 0.7.29: building configuration "libevent"...
vibe-d:http 0.7.29: building configuration "library"...
vibe-d:diet 0.7.29: building configuration "library"...
vibe-d:mail 0.7.29: building configuration "library"...
vibe-d:mongodb 0.7.29: building configuration "library"...
vibe-d:redis 0.7.29: building configuration "library"...
vibe-d:web 0.7.29: building configuration "library"...
vibe-d 0.7.29: building configuration "libevent"...
vibetest ~master: building configuration "application"...
Running ./vibetest
Fatal Error while loading '/usr/lib/libphobos2-ldc.so.70':
The module 'std.base64' is already defined in 
'./vibetest'.

Program exited with code 1

I don't even know where to start with this error. Normal projects 
without vibe.d compile and run perfectly well; replacing app.d 
contents with void main() {} still produces the same error.


[1] https://parabola.nu/


Re: Error when running vibe.d example application, not sure of the cause.

2016-09-01 Thread e-y-e via Digitalmars-d-learn

On Thursday, 1 September 2016 at 09:37:22 UTC, Kagamin wrote:

Probably LDC issue https://github.com/ldc-developers/ldc/issues


Thank you for your reply. I built LDC (version 1.1.0 beta 2) from 
source and ran dub using:


$ dub run --compiler="~/Downloads/ldc/bin/ldc2"

And everything works now, so it must have been. I looked through 
some of the issues and it surprises me that I was the only one 
having this problem, but it must have been fixed at some point.


Anyway, thanks for your time, I feel a bit silly now :)


Re: Error when running vibe.d example application, not sure of the cause.

2016-08-30 Thread e-y-e via Digitalmars-d-learn

On Monday, 29 August 2016 at 20:32:27 UTC, e-y-e wrote:

[...]


Does anyone know of anywhere else I can get help with this error? 
It's a blocker on me using vibe.d, which is quite frustrating.


Re: construct range from tuple?

2016-09-18 Thread e-y-e via Digitalmars-d-learn

On Sunday, 18 September 2016 at 08:06:54 UTC, Lutger wrote:
I have a tuple of strings generated at compile time, for 
example:


  alias names = AliasSeq!("Alice", "Bob");

How is it possible to construct a range of strings from this, 
in order to use it at runtime with other range algorithms?


For example, this

  chain(names, ["Chuck"])

doesn't work as intended because it expands to

  chain("Alice", "Bob", ["Chuck"])

I want some function makeRange that works like this:

assert(chain(makeRange(names), ["Chuck"]).fold!( (x,y) => x ~ " 
" ~ y) ==

   "Alice Bob Chuck");

What would be a good way to do that?


Use std.range's 'only' function [1], it takes variadic arguments 
of the same type and constructs a range consisting of them.


Example:

import std.meta : AliasSeq;
import std.range : only;
import std.algorithm.comparison : equal;

alias names = AliasSeq!("Alice", "Bob");

auto range = only(names, "Chuck");
assert(range.equal(["Alice", "Bob", "Chuck"]));


Re: construct range from tuple?

2016-09-18 Thread e-y-e via Digitalmars-d-learn

On Sunday, 18 September 2016 at 09:36:13 UTC, e-y-e wrote:

On Sunday, 18 September 2016 at 08:06:54 UTC, Lutger wrote:

[...]


Use std.range's 'only' function [1], it takes variadic 
arguments of the same type and constructs a range consisting of 
them.


Example:

import std.meta : AliasSeq;
import std.range : only;
import std.algorithm.comparison : equal;

alias names = AliasSeq!("Alice", "Bob");

auto range = only(names, "Chuck");
assert(range.equal(["Alice", "Bob", "Chuck"]));


[1] https://dlang.org/phobos/std_range.html#only


Can someone explain to me the design choices for this function definition?

2016-09-22 Thread e-y-e via Digitalmars-d-learn

The function in question is std.algorithm.searching's until [1].

Here are the definitions:


Until!(pred, Range, Sentinel)
until(alias pred = "a == b", Range, Sentinel)
(Range range, Sentinel sentinel, OpenRight openRight = 
OpenRight.yes)

if (!is(Sentinel == OpenRight));


and:


Until!(pred, Range, void)
until(alias pred, Range)
(Range range, OpenRight openRight = OpenRight.yes);


Now the first thing that came to mind was that it seemed odd to 
have openRight be a runtime flag instead of a compile-time flag. 
But that didn't hinder my usage of it, so I went ahead and called 
the function like so:


range.until!(e => e > f)(No.openRight)

and I got an error saying the function could not be deduced, so I 
went looking in the source code and found:



enum OpenRight
{
no,
yes
}


But I had assumed OpenRight was an alias for a Flag type [2], so 
I had called it wrong.


Does anyone have any idea why the function is defined this way?

1. Why is openRight a runtime flag? Is there really a use case 
for this?


2. Why is openRight not a Flag type?

here is the definition I was expecting:


alias OpenRight = Flag!"openRight";

auto until(alias pred = "a == b", OpenRight openRight = 
Yes.openRight, Range, Sentinel)

(Range range, Sentinel sentinel);

auto until(alias pred, OpenRight openRight = Yes.openRight)(Range 
range);


[1] https://dlang.org/phobos/std_algorithm_searching.html#until
[2] https://dlang.org/phobos/std_typecons.html#.Flag


Re: No trace of cumulativeFold except in the source.

2016-10-23 Thread e-y-e via Digitalmars-d-learn
On Sunday, 23 October 2016 at 10:19:07 UTC, Jonathan M Davis 
wrote:
On Sunday, October 23, 2016 10:10:40 e-y-e via 
Digitalmars-d-learn wrote:

...


Per

http://dlang.org/changelog/2.071.0.html

2.071.0 came out at the beginning of April, and 2.072 has been 
slow in coming, so we've only had point releases since then, 
and a new function would not be added with a point release. But 
yes, per the current release scheme, normally, there would have 
been a new major release by now (it is finally in beta though).


- Jonathan M Davis


On this topic, do you think a 'cumulativeSum' specialisation 
based on the 'sum' specialisation be welcome in phobos? Here's a 
quick prototype, obviously not library standard but the basic 
logic is there: 
https://gist.github.com/anonymous/4fb79b4aba79b59348273288993740cb


Re: No trace of cumulativeFold except in the source.

2016-10-23 Thread e-y-e via Digitalmars-d-learn
On Sunday, 23 October 2016 at 09:11:08 UTC, Jonathan M Davis 
wrote:
On Sunday, October 23, 2016 07:46:19 e-y-e via 
Digitalmars-d-learn wrote:

...


It's not a bug. It's just too new. You looked at the master 
branch on github, whereas what you're probably using on your 
computer is 2.071.2, which does not have cumulativeFold, 
because it was added at some point after 2.071.2.


- Jonathan M Davis


Ok, that checks out. I looked at the commit and it was in April 
so I just assumed it would be in the release by now.


No trace of cumulativeFold except in the source.

2016-10-23 Thread e-y-e via Digitalmars-d-learn
Recently I needed to use a cumulative sum function, so I looked 
in phobos' documentation for 'cumulative' but found nothing 
useful. Then I looked in the forums for it and found nothing 
useful. But when I searched phobos for it I found cumulativeFold 
in std.algorithm.iteration: 
https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L3127. So I tried this:


auto cumulativeSum(Range)(Range r)
{
import std.algorithm.iteration : cumulativeFold;

return r.cumulativeFold!((a, b) => a +b);
}

but when I run it I get 'Error: module std.algorithm.iteration 
import 'cumulativeFold' not found'. Anyone can reproduce this? 
looking at the source I can't see how it could possibly occur but 
it is certainly a bug right?


How to enable SIMD instructions in core.simd

2016-11-19 Thread e-y-e via Digitalmars-d-learn

Found that I was not able to use SIMD as

import core.simd : __simd;

produces the error: 'module core.simd import '__simd' not found'. 
Upon further inspection I found that the D_SIMD version is not 
defined as


version (D_SIMD)
{
pragma(msg, "SIMD Support");
}
else
{
pragma(msg, "No SIMD Support");
}

prints 'No SIMD Support' at compile time. In the docs for SIMD 
[1] I can see the line 'Depending on the architecture, compiler 
flags may be required to activate support for SIMD types.', but 
no information on which architectures and more importantly what 
the compiler flags are.


My architecture is Intel x86_64 and I am using dub with latest 
ldmd. How would I enable SIMD instructions in a simple way? (I 
have another issue with dub & compiler arguments also but I can 
create another thread if that continues to bother me)


Thanks in advance.

[1] https://dlang.org/spec/simd.html


Re: How to enable SIMD instructions in core.simd

2016-11-19 Thread e-y-e via Digitalmars-d-learn

On Saturday, 19 November 2016 at 13:11:18 UTC, e-y-e wrote:

...


Sorry for the noise, I found an LDC issue [1] that explains where 
I am going wrong (in short, core.simd is not supported in LDC, 
instead ldc.simd should be used).


[1] https://github.com/ldc-developers/ldc/issues/595


Re: [Semi-OT] I don't want to leave this language!

2016-12-05 Thread e-y-e via Digitalmars-d-learn

On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:

Hi e-y-e,

The main problem with D for production is its runtime. GC, 
DRuntime, Phobos is big constraint for real world software 
production.


Good D code should be nothrow, @nogc, and betterC. BetterC 
means that it must not require DRuntime to link and to start. I 
started Mir as scientific/numeric project, but it is going to 
be a replacement for Phobos to use D instead/with of C/C++.


For example, Mir CPUID, Mir GLAS, Mir Random are nothrow @nogc 
and do not need DRuntime to start/link. (Mir Random is not 
tested for BetterC, so maybe few dependencies are exist.) Mir 
Random covers C++11 random number generation for example.


If D code can be compiled into a common C libraries like Mir 
libs, than you can include it into existing ecosystem. 
Currently it is possible only with LDC (requires some 
programming techniques for now).


I will be happy to see more Mir contributors [1]

Currently there are 5 Mir devs (not all are visible publicly).

[1] https://github.com/libmir

Cheers,
Ilya


You know from the 15th December I will have a month of free time, 
and I would love to get myself up to speed with Mir to contribute 
to it. If you don't mind me saying, I think Mir could be one of 
the best things for the future of D (along with LDC) and I'd be 
glad to help it on its way.


[Semi-OT] I don't want to leave this language!

2016-12-05 Thread e-y-e via Digitalmars-d-learn
Currently I have been learning D for about a year and a half. 
This may seem like a short time, but this is the longest I have 
stuck with any language. I have only been learning for 4 years 
and I am currently in university studying first year of computer 
systems engineering.


My main problem is that now I am looking for industry placements, 
it is clear that in this field C and C++ are highly desired. I 
have used C++ prior to discovering D, but much of my learning 
curve has occured while using D, and I feel quite comfortable 
using it. Using D makes me look back at what a great language it 
is compared to C++ (I know it can also be compared to C but I 
haven't used C).


So I don't want to go back. It isn't as if I have a career in C++ 
(like I know some people here have) and use D (only) for pleasure 
so I have no real knowledge of how things I write in D compare to 
what I would do in C++ (and none whatsoever for C).


Does anyone have any advice for me? Obviously I'm going to have 
to make this leap and the organizations will have their own 
ecosystem but while I'm learning how can I replace some of the 
great things about D? Things like built-in unittests, sane static 
if, painless CTFE, ranges, or even just the DUB package 
manager/build tool.


Failing that, think of this as another one of those 'D is great!' 
posts ;). And whatever happens, I'll certainly try and convince 
my host company to use it...