Re: OneDrive Client written in D

[frieder via Digitalmars-d-announce]

On Wednesday, 23 September 2015 at 04:30:23 UTC, Rikki Cattermole 
wrote:

On 23/09/15 8:43 AM, skilion wrote:
I've been waiting for a good sync client for OneDrive (15 GB 
for free!)

on Linux, but Microsoft seems to have other plans...
So I've decided to write my own, using D. Take a look:

   http://skilion.github.io/onedrive/


You probably should not be exposing developer information for 
authentication.
You need to get the authentication fixed. Users should login 
via user/pass.


Once that is done, get that on Reddit! It is awesome!



... good work. I appreciate it very much.

Just one note systemd:

systemctl --user enable onedrive
systemctl --user start one drive

requires libpam-systemd

This is not in all Debian Jessie distributions! Otherwise you 
will get a "Failed to get D-Bus connection - Connection refused"



Regards Frieder

Re: Battle-plan for CTFE

[Martin Nowak via Digitalmars-d-announce]

On 05/21/2016 11:18 PM, Martin Nowak wrote:
> The debugging metaphor would be comparing a program that only uses
> pointer arithmetic against one that is memory safe, the former can
> randomly write everywhere from anywhere, the latter could use the wrong
> reference.

It's also similar to comparing assembly code to C.

Re: Battle-plan for CTFE

[Martin Nowak via Digitalmars-d-announce]

On 05/18/2016 04:59 PM, Daniel Murphy wrote:
> The bytecode generator and bytecode interpreter can be debugged (and
> tested!) independently.  So the total amount of code will increase but
> the components themselves will be better isolated and easier to work with.

It's simpler to debug an AST interpreter working with a stack of
high-level values, than it is to debug a bytecode interpreter where lots
of context has been converted to jumping goto code.

Just to illustrate my point, here are an AST and a BC interpreter for
very simplistic functional language I wrote recently. The later one
still missing the actual interpretation.
https://github.com/MartinNowak/CC1/commit/ed28b8966de86e7449f93ce4e4cf7aed3082180b
https://github.com/MartinNowak/CC1/commit/899e67cf7038050b86eed533c9165bd2ba06e609

There is nothing simpler about a BC interpreter. Instead you have to
deal with converting control flow and computing addressing.

The debugging metaphor would be comparing a program that only uses
pointer arithmetic against one that is memory safe, the former can
randomly write everywhere from anywhere, the latter could use the wrong
reference.

> I don't think a possible future need for a JIT is a good reason to avoid
> an bytecode interpreter.

It's a very good reason, b/c once you work on JIT, there is no benefit
for BC left, e.g. all the extra work for nothing.
That said, I doubt we'll need a JIT anytime soon.

> A large part of the work of adding a new (JIT) backend is pinning down the 
> semantics,
> and adding a bytecode interpreter will certainly help to do that.

The semantic problem is already solved, in a file called interpret.d by
sth. that's an AST interpreter, that just happens to use the wrong value
structures and leaks memory. Converting that to BC will be quite
difficult, cleaning it up and changing it to use a better stack and
deterministic memory management is rather straightforward.

Last but not least, don't forget that we have the same situation since
over 3 years already. It has always been similarly easy to write a
better interpreter, it just never happened b/c the ambitions never
matched the available resources.

-Martin

Re: Battle-plan for CTFE

[Martin Nowak via Digitalmars-d-announce]

On 05/18/2016 07:50 PM, Stefan Koch wrote:
> Indeed.
> 
> I am currently designing an IR to feed into the CTFE Evaluator.
> I am aware that this could potentially make it harder to get things
> merged since DMD already has the glue-layer.

As a compat layer between different interpreters or as a compat layer
between all backends? Adding another translation might not be
acceptable, at least for real backends.

> However I do think that the benefits outweigh the drawbacks by far.
> Especially when one looks at the possibility to eventually plug llvm or
> the gcc-jit in.

Indeed, but it heavily increases the chance that your project lands on
the unfinished D project pile.

> My CTFE needs are rather heavy weight. So I will go for a solution that
> can support this.
> I believe the pressure on CTFE performance will increase as soon as the
> preformance increases. Since this will enable much more things.
> I.E. running a query optimizer at compile-time.

That might be true, but scripting languages are still fast enough to be
used everywhere. You won't need native CTFE performance for it to be an
enabling technique.

-Martin

Re: Diamond - MVC / Template engine

[Bauss via Digitalmars-d-announce]

On Saturday, 21 May 2016 at 19:46:38 UTC, Vladimir Panteleev 
wrote:

On Saturday, 21 May 2016 at 08:20:00 UTC, Bauss wrote:
Just finished up the base for Diamond and its initiate state 
with Github and Dub, as well the first guide on using Diamond 
with vibe.d for websites.


The name is taken :)

https://github.com/CyberShadow/Diamond

I don't mind though.


Well I didn't see it in the dub repository, so I didn't assume 
anyone had used the name, so didn't assume anything existed with 
it.


I apologize for the inconvenience though.

Re: Diamond - MVC / Template engine

[Vladimir Panteleev via Digitalmars-d-announce]

On Saturday, 21 May 2016 at 08:20:00 UTC, Bauss wrote:
Just finished up the base for Diamond and its initiate state 
with Github and Dub, as well the first guide on using Diamond 
with vibe.d for websites.


The name is taken :)

https://github.com/CyberShadow/Diamond

I don't mind though.

Re: Diamond - MVC / Template engine

[Bauss via Digitalmars-d-announce]

On Saturday, 21 May 2016 at 11:02:41 UTC, Bauss wrote:

On Saturday, 21 May 2016 at 10:02:17 UTC, Chris wrote:

On Saturday, 21 May 2016 at 08:20:00 UTC, Bauss wrote:
[snip]

Sounds interesting. Are you planning to add a tutorial / more 
examples?


Typo on your Github page:

"on every playform that can compile D"

playform => platform


Thank you and yes, there's a few wiki pages at the moment.


Just finished stand-alone support and added a "guide" on how to 
use it. There are currently 3 guides on using it for websites, 
webservices and as stand-alone.


Next thing coming up is a website for the whole thing :)

This marks the last "initial" alpha version 0.2.3

The plan is to have monthly releases with stable versions.

Re: amoeba, a chess engine written in D

[Richard Delorme via Digitalmars-d-announce]

On Saturday, 21 May 2016 at 08:23:59 UTC, Johan Engelen wrote:

On Friday, 20 May 2016 at 23:16:01 UTC, Richard Delorme wrote:


The source can be compiled with dmd, ldc or gdc, but the best 
performance are obtained with the latter (almost twice faster).


Can you give cmdline details and compiler version data for 
this? (how much faster is gdc relative to ldc?)


I used the following compiler versions,

dmd: DMD64 D Compiler v2.071.0
ldc: 0.17.0-beta2 (DMD v2.068.2, LLVM 3.7.1)
gdc: gcc version 5.2.0 (crosstool-NG 203be35 - 
20160205-2.066.1-e95a735b97)


to compile, you can use the following commands:
$ DC=ldc2 make amoeba (to compile with ldc)
$ DC=dmd make amoeba (to compile with dmd)
$ DC=gdc make amoeba  (to compile with gdc)
$ make amoeba (use gdc by default)
$ make pgo (for profile guided optimization),
$ make pgo BUILD=popcount (to use the CPU popcnt instruction)
With the above versions & my poor knowledge of the compilers, pgo 
& BUILD=popcount only worked with gdc. I will try to upgrade to 
more recent versions to see if things changed.


to test the speed , you can do:
amoeba bench -f bk.epd -d 14

Here is what I get on my computer (an old i7 2600k at 4Ghz):
dmd: 24 positions  29981105 nodes in 20.000s : 1499024 nps, 
depth = 13.71
   ldc2: 24 positions  29981105 nodes in 18.340s : 1634711 nps, 
depth = 13.71
gdc: 24 positions  29981105 nodes in 12.005s : 2497388 nps, 
depth = 13.71
gdc+pgo: 24 positions  29981105 nodes in 10.224s : 2932328 nps, 
depth = 13.71
* gdc used the BUILD=popcount options. without, it is slower, 
doing the test in 15.4. & 13.6 s., respectively for gdc & gdc + 
pgo. So gdc benefits a lot from both pgo and using the popcnt 
instruction.


--
Richard

Re: d-vulkan, automatically generated D bindings for Vulkan

[Alex Parrill via Digitalmars-d-announce]

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

https://github.com/ColonelThirtyTwo/dvulkan


I've updated the bindings to Vulkan 1.0.13, and added a few fixes.

Platform support will come in a bit. I'm going to use void* 
pointers for most of the platform-specific types, so you can use 
whatever bindings you want to use with them (whether they are 
full bindings or just one little opaque struct alias to use with, 
say, glfw).

Re: My ACCU 2016 keynote video available online

[Manu via Digitalmars-d-announce]

On 21 May 2016 at 23:20, Andrei Alexandrescu via
Digitalmars-d-announce  wrote:
> On 05/21/2016 04:45 AM, Manu via Digitalmars-d-announce wrote:
>>
>> On 20 May 2016 at 18:26, Walter Bright via Digitalmars-d-announce
>>  wrote:
>>>
>>> On 5/19/2016 11:50 PM, Manu via Digitalmars-d-announce wrote:


 Ah. Okay, well while this is a very interesting talk, I was indeed
 hoping you were going to make a D concepts proposal... do you have
 such a thing in mind, or are you against concepts in D?
>>>
>>>
>>>
>>> D has constraints. No point in adding concepts.
>>
>>
>> I really struggle to agree. Constraints are a good first-step in that
>> direction, but they're unwieldy, produce the worst looking function
>> signatures (read: documentation) of literally any language ever
>> conceived, relatively awkward error feedback, and very quickly get out
>> of hand if you have many variations of possible constraints.
>
>
> I guess a lot more detail would be necessary here. A bunch of good folks (at
> least better than me) have worked for over a decade on C++ concepts and
> three (three!) proposals later it's still unclear whether they're a good
> idea. -- Andrei

I agree it's not clear to me either. I haven't seen any proposals for
D. Have there been any?
Constraints obviously work, but I do constantly find myself wishing
there were something a little bit closer to the type system.
I generally like where C++ is going. I think part of the problem with
C++, as always, is that they are in a constant struggle to bolt things
on to an ancient language with so many existing spiky angular edge
cases that it always seems to become awkward.

I think my biggest gripe with constraints in D though, is that they
are quite pervasive when you start to produce generic API's, and the
documentation becomes a massive problem.
Every single person (seriously) I've ever introduced to D has
struggled with the phobos docs as soon as constraints are presented.
Many of us have raised this many times, and we've had a lot of
discussion and various experiments with improving the documentation
wrt existing constraints. I'm not sure we've doing a good
documentation solution her, and I'm not even confident there's a good
solution there. I just don't think it's a great way to express the
problem. Concepts, or something like it, feels a lot more intuitive to
me, and certainly lends much nicer to documentation and API
presentation.

Re: My ACCU 2016 keynote video available online

[Leontien Smaal via Digitalmars-d-announce]

On Friday, 20 May 2016 at 19:34:11 UTC, Walter Bright wrote:
Constraints can address behavior and relationships, concepts do 
not.


Wow, TIL. That's so clear once said !
There's been several discussion here and even one phobos PR that 
proposes a kind of concepts but I didn't realize before that the 
2 things are different.


The problem I see in D is that the constraints, since they 
prevent to output a good message, are doing both (in a way):


void foo(T)(T t)
if (constraint)
{
// cannot have the message if constraint fails...
static assert((checkConcept!T).ok, (checkConcept!T).message);
}

At the language level it would work

void foo(T)(T t) @Concept(CheckerTemplate) // use this to output 
a smart message

if (constraint)
{

}

But really, without changing much what I'd like to see is a DMD 
feature that
would parse and evaluate the constraints to output a message: 
such as


void foo(T)(T t)
if ((a || b) && (a || b))
{
}


error:(a || b) is false


instead of throwing the whole constraint text in the output.

Re: My ACCU 2016 keynote video available online

[Manu via Digitalmars-d-announce]

On 21 May 2016 at 19:55, Stefan Koch via Digitalmars-d-announce
 wrote:
> On Saturday, 21 May 2016 at 08:45:45 UTC, Manu wrote:
>>
>> Constraints are a good first-step in that direction, but they're unwieldy,
>> produce the worst looking function signatures (read: documentation) of
>> literally any language ever conceived, relatively awkward error feedback,
>> and very quickly get out of hand if you have many variations of possible
>> constraints.
>
>
> Constraints are enough for simple matters.
> As soon as they are used to distinguish between many overloads with
> complicated relationships they become slightly crude.
>
> However this can be worked around with having static ifs and static
> asserts(0).
> I find myself just one variadic template with a lot of static ifs branches.

I also find myself taking that route when I run into cases where there
are numerous constraint combinations. It's better in some ways, but
worse in others.
I think it simplifies API's, but at the same time, it removes
information from the API, and takes away a lot of documentation.

Re: My ACCU 2016 keynote video available online

[Andrei Alexandrescu via Digitalmars-d-announce]

On 05/21/2016 04:45 AM, Manu via Digitalmars-d-announce wrote:

On 20 May 2016 at 18:26, Walter Bright via Digitalmars-d-announce
 wrote:

On 5/19/2016 11:50 PM, Manu via Digitalmars-d-announce wrote:


Ah. Okay, well while this is a very interesting talk, I was indeed
hoping you were going to make a D concepts proposal... do you have
such a thing in mind, or are you against concepts in D?



D has constraints. No point in adding concepts.


I really struggle to agree. Constraints are a good first-step in that
direction, but they're unwieldy, produce the worst looking function
signatures (read: documentation) of literally any language ever
conceived, relatively awkward error feedback, and very quickly get out
of hand if you have many variations of possible constraints.


I guess a lot more detail would be necessary here. A bunch of good folks 
(at least better than me) have worked for over a decade on C++ concepts 
and three (three!) proposals later it's still unclear whether they're a 
good idea. -- Andrei

Re: [OT] Re: pl0stuff an optimizing pl0 > c transcompiler

[Stefan Koch via Digitalmars-d-announce]

On Friday, 20 May 2016 at 19:20:34 UTC, Johan Engelen wrote:

On Friday, 20 May 2016 at 18:04:55 UTC, Stefan Koch wrote:


Update I have implemented D codegen.
The CodeGenerator as well as the optimizer work at CTFE.
Therefore you can transcompile code at compileTime at call 
PL/0 functions as there were naively implemented in D.


This is pretty cool :D

Now I understand why you want to improve CTFE. You actually 
want better C++ interop. And to do that, you are going to CTFE 
compile the C++ code to D code, which is then mixed in, and all 
is good. Excellent idea! ;-)


cheers,
  Johan


Actually I think compiling c++ is a bit out of my league at the 
moment.
It would only work for self-contained subset of c++. Not for the 
whole c++ language.

Especially preprocessor tricks make this approach unfeasible.

Re: Diamond - MVC / Template engine

[Bauss via Digitalmars-d-announce]

On Saturday, 21 May 2016 at 10:02:17 UTC, Chris wrote:

On Saturday, 21 May 2016 at 08:20:00 UTC, Bauss wrote:
[snip]

Sounds interesting. Are you planning to add a tutorial / more 
examples?


Typo on your Github page:

"on every playform that can compile D"

playform => platform


Thank you and yes, there's a few wiki pages at the moment.

Re: amoeba, a chess engine written in D

[Richard Delorme via Digitalmars-d-announce]

On Saturday, 21 May 2016 at 00:29:13 UTC, extrawurst wrote:

Two questions:
1) If it is using UCI protocol I guess there are other engines 
that you can compare amoeba with when it comes to performance 
and other aspects, did you ?


Yes, It is a strong program, but far from the top programs yet.
In the ccrl scale: http://www.computerchess.org.uk/ccrl/4040/
I guess its rating is close to 2700.
The move generator is pretty fast, though:
$ amoeba-linux-x64-sse4.2 perft -d 7
perft  7 :  3195901860 leaves in 17.920 s178344094 
leaves/s


In comparison, stockfish 7, one of the strongest chess program in 
C++:

$ stockfish-7
perft 7
[...]
Total time (ms) : 16669
Nodes searched  : 3195901860
Nodes/second: 191727269

So my implementation of a different algorithm in D is only 7% 
slower at generating moves, which is negligible in the overall 
program.


2) It would be awesome if you could write down how it was to 
use D for that project as someone freshly coming from C. What 
were the reasons you chose D, what did you like, what did u 
hate ? That would help you being read on reddit by a hundred 
blood thursty devs (street cred and all) and us for knowing 
what we can improve and also get the PR :)


Good idea, I will try to write something clever and constructive 
within the next days.


--
Richard

Re: Diamond - MVC / Template engine

[Chris via Digitalmars-d-announce]

On Saturday, 21 May 2016 at 08:20:00 UTC, Bauss wrote:
[snip]

Sounds interesting. Are you planning to add a tutorial / more 
examples?


Typo on your Github page:

"on every playform that can compile D"

playform => platform

Re: My ACCU 2016 keynote video available online

[Stefan Koch via Digitalmars-d-announce]

On Saturday, 21 May 2016 at 08:45:45 UTC, Manu wrote:
Constraints are a good first-step in that direction, but 
they're unwieldy, produce the worst looking function signatures 
(read: documentation) of literally any language ever conceived, 
relatively awkward error feedback, and very quickly get out of 
hand if you have many variations of possible constraints.


Constraints are enough for simple matters.
As soon as they are used to distinguish between many overloads 
with complicated relationships they become slightly crude.


However this can be worked around with having static ifs and 
static asserts(0).
I find myself just one variadic template with a lot of static ifs 
branches.

Re: My ACCU 2016 keynote video available online

[Manu via Digitalmars-d-announce]

On 20 May 2016 at 18:26, Walter Bright via Digitalmars-d-announce
 wrote:
> On 5/19/2016 11:50 PM, Manu via Digitalmars-d-announce wrote:
>>
>> Ah. Okay, well while this is a very interesting talk, I was indeed
>> hoping you were going to make a D concepts proposal... do you have
>> such a thing in mind, or are you against concepts in D?
>
>
> D has constraints. No point in adding concepts.

I really struggle to agree. Constraints are a good first-step in that
direction, but they're unwieldy, produce the worst looking function
signatures (read: documentation) of literally any language ever
conceived, relatively awkward error feedback, and very quickly get out
of hand if you have many variations of possible constraints.

Re: amoeba, a chess engine written in D

[Iain Buclaw via Digitalmars-d-announce]

On 21 May 2016 at 10:23, Johan Engelen via Digitalmars-d-announce
 wrote:
> On Friday, 20 May 2016 at 23:16:01 UTC, Richard Delorme wrote:
>>
>>
>> The source can be compiled with dmd, ldc or gdc, but the best performance
>> are obtained with the latter (almost twice faster).
>
>
> Can you give cmdline details and compiler version data for this? (how much
> faster is gdc relative to ldc?)
>

I think he meant that ldc or gdc is twice as fast.

Re: amoeba, a chess engine written in D

[Johan Engelen via Digitalmars-d-announce]

On Friday, 20 May 2016 at 23:16:01 UTC, Richard Delorme wrote:
I am pleased to announce the release of a chess engine written 
in D:

https://github.com/abulmo/amoeba


In the makefile, I see you tried LDC's PGO, awesome! I hope to 
get (part of) it into LDC master very soon. All feedback is very 
welcome.


(small typo: better use ldc-profdata instead of llvm-profdata)

cheers,
  Johan

Re: amoeba, a chess engine written in D

[Johan Engelen via Digitalmars-d-announce]

On Friday, 20 May 2016 at 23:16:01 UTC, Richard Delorme wrote:


The source can be compiled with dmd, ldc or gdc, but the best 
performance are obtained with the latter (almost twice faster).


Can you give cmdline details and compiler version data for this? 
(how much faster is gdc relative to ldc?)


Thanks,
  Johan

Diamond - MVC / Template engine

[Bauss via Digitalmars-d-announce]

Just finished up the base for Diamond and its initiate state with 
Github and Dub, as well the first guide on using Diamond with 
vibe.d for websites.


Diamond is a MVC / Template framework originally made for a hobby 
project, but as I developed it further I saw some potential in it 
and have now decided to make it open-source.


It can be used to write websites/webservices on-top of vibe.d 
Allowing you to easily create and run websites/webservices 
without a lot of configurations to vibe.d since it's all done 
through simple configuration files in json, as well handled 
behind the scenes within the core framework of Diamond.


Diamond however is also a template framework for views 
(Originally designed for web-views only.) and thus can be used to 
render MVC websites using its own syntax, heavily inspired by the 
ASP.NET razor syntax; not entirely though.


It's currently in its first stable alpha version (0.2.2)

For more information please view below.

Dub repository:
https://code.dlang.org/packages/diamond

Github:
https://github.com/bausshf/Diamond