Re: OneDrive Client written in D
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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