Re: D IDE Coedit - version 3, update 3 released
On Friday, 14 July 2017 at 06:10:08 UTC, Basile B. wrote: Better integration of D-Scanner. D-Scanner binary is itself included from now, in addition to DCD. See https://github.com/BBasile/Coedit/releases/tag/3_update_3 for the download links and a complete changelog. update 4 is available too: https://github.com/BBasile/Coedit/releases/tag/3_update_4 mostly fixes at first glance.
Re: Article: Writing Julia style multiple dispatch code in D
On Friday, 25 August 2017 at 00:35:24 UTC, jmh530 wrote: What you seem concerned about here is how to produce a meaningful error message for distribution that you do not have implementations for. A slightly more elegant solution would be to pack the structs into an AliasSeq and then use something like !allSatisfies to test them all. I'm sure there's a more elegant solution, but that's the first thing I thought of. Andrei suggested allSatisfies that as an alternative approach to a Union keyword similar to Julia, at the time I was still stuck on how cool having a Union keyword like Julia's in D would be. immutable class(T...){...} What you're looking for is an immutable constructor: class C { this() immutable; } Aha, thanks!
Re: Article: Writing Julia style multiple dispatch code in D
On Thursday, 24 August 2017 at 23:50:21 UTC, data pulverizer wrote: ``` double density(D: UnivariateDistribution!Discrete, U = getVariateType!D, T = GetDistributionParameterType!D)(D d, U x) if(!is(D == Poisson!T)) { assert(false, "density function unimplemented for this distribution: " ~ D.stringof); } double density(D: UnivariateDistribution!Continuous, U = getVariateType!D, T = GetDistributionParameterType!D)(D d, U x) if(!is(D == Gamma!T) && !is(D == Gaussian!T) && !is(D == Uniform!T) && !is(D == Exponential!T)) { assert(false, "density function unimplemented for this distribution: " ~ D.stringof); } What you seem concerned about here is how to produce a meaningful error message for distribution that you do not have implementations for. A slightly more elegant solution would be to pack the structs into an AliasSeq and then use something like !allSatisfies to test them all. I'm sure there's a more elegant solution, but that's the first thing I thought of. immutable class(T...){...} that this class can only create immutable objects without having to write immutable everywhere and or a UDA, but making every member immutable accomplishes the same thing. What you're looking for is an immutable constructor: class C { this() immutable; }
Re: D as a Better C
On Thursday, 24 August 2017 at 19:21:31 UTC, Walter Bright wrote: On 8/24/2017 11:56 AM, Walter Bright wrote: I find -betterC to be somewhat of a copout for avoiding the hard work of improving D's implementation. On the contrary, I view it as providing motivation for dealing with those issues. The PR above is stalled for lack of motivation. -betterC also brings into sharp focus exactly what the issues are. Great! I look forward to seeing improvements and hope to help. Allow me to point out a recent pull request that should have resulted in an improvement in the full-featured D implementation rather than the -betterC implementation. https://github.com/dlang/dmd/pull/6918 DMD should never link in Phobos or druntime automatically. Rather, I think such dependencies should be specified on a platform-by-platform basis using a dmd.conf, linker script, or some other configuration file that is distributed with the toolchain's package. This puts the power in the hands of the user to avoid linking in Phobos and druntime without having to use the -betterC switch which is especially useful if the user is providing their own minimal runtime implementation to support features of D that are excluded with the heavy hand of -betterC. Mike
Re: D as a Better C
On Thursday, 24 August 2017 at 18:26:37 UTC, H. S. Teoh wrote: For instance, a D project targeting STM board, makes heavy use of classes and templates, resultant code segment is 3k. https://github.com/JinShil/stm32f42_discovery_demo#the-good To be fair, though, the above-mentioned project did have to create a stub druntime in order to get things to work. Not everyone may have the know-how required to construct a minimal druntime that works for their purposes. Those runtime stubs are needed precisely because of problems in D's implementation. If the implementation were fixed, none of those stubs would be required, and neither would the -betterC switch. Because the project above is not using any feature provided by those runtime stubs, those stubs should not be required, and neither should the -betterC switch. GDC has made some improvements here, and that is why the project above only compiles with GDC. LDC doesn't even display an error message when those stubs aren't created. Instead it enters a codegen loop generating a gargantuan multi-gigabyte file, ultimately crashing my VM (https://github.com/ldc-developers/ldc/issues/781). Sometimes, however, it is not known whether a runtime feature will be needed until link-time. In that case, it's OK for the compiler to emit TypeInfo, ModuleInfo, etc..., but it should do so in a way that the linker (with either LTO or --gc-sections) can determine what is needed and what isn't and discard that which isn't needed. Once unneeded object code is discarded, the linker errors disappear, and you get a functioning executable without linking in the runtime and without a -betterC switch. GDC recently implemented such an improvement (https://github.com/D-Programming-GDC/GDC/pull/505). It brought my binary size from 600kB to 6KB, so now I can get back to microcontroller programming in D. This is the kind of work that's needed. Mike
Re: Article: Writing Julia style multiple dispatch code in D
On Thursday, 24 August 2017 at 21:13:10 UTC, jmh530 wrote: On UDAs, at least in the current implementation, I think that the actual issue you are trying to address is to force the type in the distribution to be convertible to double in the continuous case and convertible to long in the discrete case. All things considered, that can be implemented with template constraints, as in class Gamma(T): if(isFloatingPoint!T) { immutable(T) shape; immutable(T) scale; this(T shape, T scale) { this.shape = shape; this.scale = scale; } } Okay, I admit that I try to avoid using template constraints whenever I can - i.e. unless the code breaks! It's a habit I am trying to break. In reality I will have to have them everywhere and the code will end up looking much less pretty, in reality, I know I'll probably need one or two catchall functions that look something like this ``` double density(D: UnivariateDistribution!Discrete, U = getVariateType!D, T = GetDistributionParameterType!D)(D d, U x) if(!is(D == Poisson!T)) { assert(false, "density function unimplemented for this distribution: " ~ D.stringof); } double density(D: UnivariateDistribution!Continuous, U = getVariateType!D, T = GetDistributionParameterType!D)(D d, U x) if(!is(D == Gamma!T) && !is(D == Gaussian!T) && !is(D == Uniform!T) && !is(D == Exponential!T)) { assert(false, "density function unimplemented for this distribution: " ~ D.stringof); } ``` She's not so pretty anymore captain! This is why some time ago I suggested introducing the Union keyword that Julia has https://forum.dlang.org/post/lkcmqlpsdcopfebwg...@forum.dlang.org though you could probably take a more abstract approach. (I'm also not 100% on having immutable member variables). I am 100% sure that I want either the instantiated distribution object to be immutable, or the parameters to be immutable once instantiated. Its a safety feature that I don't see a need for mutable distribution objects. Once the parameters change, its not the same distribution. Ideally I want to be able to say immutable class(T...){...} that this class can only create immutable objects without having to write immutable everywhere and or a UDA, but making every member immutable accomplishes the same thing. Also, density's signature could then avoid the template constraint. auto density(D: Gamma!T, U : T, T)(D d, U x) Sorry U is not T, T is the type of the parameters, U is the type of the variate. Even better, if you're calling the dstats functions, you could re-write density as something like auto pdf(D: Dist!T, U : T, Dist, T)(U x, D d) { mixin("return x." ~ lookupdstatdensity!Dist ~ "(" ~ stringmembersofd ~ ")"; } and create a lookupdstatdensity function that returns a string of the relevant dstats function at compile-time (and a function returning a string of the members of d) (I also would re-name density to pdf and switch the order of x and d). This would probably be the most DRY approach. Sounds like a reasonable approach, though I haven't looked at the dstats package in great detail. Julia is a scripting language with a JIT compiler. So if you call a function with some types known at compile time and the overload exists, it will compile the correct version of the function for the relevant types. Yes, I guess you could say that Julia is an interactive compiler, where you can create new compiled types and methods in the same session. So it's similar to what you're doing on that respect. However, there is a runtime dispatch component that would take something like openmethods to implement, I think. I find OOP-polymorphic types ultimately unsatisfying, but I don't know of anyway to write, compile and load a D script with new types and methods on the fly into the same session.
Re: D as a Better C
On Thursday, 24 August 2017 at 18:56:25 UTC, Walter Bright wrote: There is a PR to make it only on demand, https://github.com/dlang/dmd/pull/6561 but it is mired in problems that are not in the D test suite and for which no test cases exist. C++ compilers also have a switch, like -fno-rtti, for de-activating RTTI. BetterC seems like a combination of several pieces of underlying functionality. There is not yet any ability to have any kind of granularity. For instance, -betterC=[flag] where [flag] might be something like "off-dassert" which calls the C assert function instead of the D one.
Re: Visual Studio Code code-d serve-d beta release
On Thursday, 24 August 2017 at 08:21:41 UTC, Paolo Invernizzi wrote: On Wednesday, 23 August 2017 at 20:10:01 UTC, WebFreak001 wrote: [...] Can you check? If I want to build it, what repo and revision should I use? [...] git clone https://github.com/Pure-D/serve-d.git cd serve-d dub build --build=release
Re: Article: Writing Julia style multiple dispatch code in D
On Thursday, 24 August 2017 at 20:11:32 UTC, data pulverizer wrote: Thanks. I think most of that is down to D's nice syntax and how it easily and clearly emulates Julia. I think that there is certainly more to say on this especially around strategies of how represent concrete types. David Gileadi's point about UDAs could add an interesting spin on things, and Ali's point on dynamic dispatching. On UDAs, at least in the current implementation, I think that the actual issue you are trying to address is to force the type in the distribution to be convertible to double in the continuous case and convertible to long in the discrete case. All things considered, that can be implemented with template constraints, as in class Gamma(T): if(isFloatingPoint!T) { immutable(T) shape; immutable(T) scale; this(T shape, T scale) { this.shape = shape; this.scale = scale; } } though you could probably take a more abstract approach. (I'm also not 100% on having immutable member variables). Also, density's signature could then avoid the template constraint. auto density(D: Gamma!T, U : T, T)(D d, U x) Even better, if you're calling the dstats functions, you could re-write density as something like auto pdf(D: Dist!T, U : T, Dist, T)(U x, D d) { mixin("return x." ~ lookupdstatdensity!Dist ~ "(" ~ stringmembersofd ~ ")"; } and create a lookupdstatdensity function that returns a string of the relevant dstats function at compile-time (and a function returning a string of the members of d) (I also would re-name density to pdf and switch the order of x and d). This would probably be the most DRY approach. On Ali's point on dynamic dispatching, Julia is a scripting language with a JIT compiler. So if you call a function with some types known at compile time and the overload exists, it will compile the correct version of the function for the relevant types. It will then cache that so that if you need it again you don't pay any additional cost. So it's similar to what you're doing on that respect. However, there is a runtime dispatch component that would take something like openmethods to implement, I think.
Re: Article: Writing Julia style multiple dispatch code in D
On Thursday, 24 August 2017 at 18:16:21 UTC, jmh530 wrote: I think at one point I had actually suggested that dstats or something be re-written in a Julia-like way (before I realized how much work that would be!). It looks very pretty. Thanks. I think most of that is down to D's nice syntax and how it easily and clearly emulates Julia. I think that there is certainly more to say on this especially around strategies of how represent concrete types. David Gileadi's point about UDAs could add an interesting spin on things, and Ali's point on dynamic dispatching. Nevertheless, you might be re-inventing the wheel a bit if you want to build a whole library in this style. True. I have found a couple of projects that fresh targets that I am working on and writing code in this style. My recommendation would be to write a front-end for the dstats.distrib and dstats.random submodules in this style. That way you won't need to re-write all the functions, you can just call ones from dstats that have already been tested. True code reuse is important, especially when you want to get something working quickly. More generally, I prefer the structs because they don't rely on the garbage collector, but the class/interface version is prettier. Aha! I was wandering why I see people avoid classes even when using them is clearly the best way to represent their objects. For some reason it never occurred to me that they where just trying to avoid the GC. I just thought they didn't want to use reference objects. Atila's concepts library has implements, which you might find helpful. I have gently nudged him to work on something that also can tell if a type is a subtype of another type more generally (like a struct being a subtype of another struct). I think this would really be a good use case for that functionality. I was thinking about this article for some time, it was Atila's article (https://atilanevesoncode.wordpress.com/2017/08/23/on-the-novelty-factor-of-compile-time-duck-typing/) that was a trigger for me writing it.
Re: Beta 2.076.0
On Friday, 18 August 2017 at 12:58:18 UTC, Martin Nowak wrote: First beta for the 2.076.0 release. This release comes with various phobos additions and lots of improvements for -betterC (changelog entry upcoming). http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.076.0.html Please report any bugs at https://issues.dlang.org - -Martin I have a warning about the RPM package signature. It was already the case with 2.075.1
Re: D as a Better C
On 8/24/2017 11:56 AM, Walter Bright wrote: I find -betterC to be somewhat of a copout for avoiding the hard work of improving D's implementation. On the contrary, I view it as providing motivation for dealing with those issues. The PR above is stalled for lack of motivation. -betterC also brings into sharp focus exactly what the issues are.
Re: D as a Better C
On Wed, Aug 23, 2017 at 10:17 AM, Kagamin via Digitalmars-d-announce wrote: > Not a better C, but intermediate D has small footprint for me too. What is "intermediate D"? -Parke > 7.5kb totext.exe (encodes stdin to base64 and writes to stdout) - wrote it > to put images in xml for opensearch descriptions. > 12.5kb retab.exe (retabifies source code with various features) > 5.5kb keepower.exe (manages screen saver and power settings because of > obnoxious domain policy) > 14.5kb fsum.exe (computes various hash sums of a file) > > Additional features: string switch, array cast. Also how assert failure > works in C? Mine shows a nice formatted message.
Re: D as a Better C
On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote: To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on the D blog about what it is and why to use it. A fun read. And I'm personally happy to see the love this feature is getting. I have a project I'd like to use it with if I can ever make the time for it! The blog: https://dlang.org/blog/2017/08/23/d-as-a-better-c/ Reddit: https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/ Questions regarding c++ classes in betterC mode. Can the c++ class destructor be called by the destroy function or do I have to call it explicitly like p-<~class()? Alex
Re: D as a Better C
On 8/23/2017 5:35 PM, Michael V. Franklin wrote: Consider this: Rust doesn't need a special switch to make it interoperable with C. What's wrong with D's implementation that requires such things? Granted, D is not Rust, but D's implementation could be improved to make it more competitive with Rust in these use cases. For example, there is really no need for TypeInfo if you're not doing any dynanmic casts, but the current implementation generates it regardless. There is a PR to make it only on demand, https://github.com/dlang/dmd/pull/6561 but it is mired in problems that are not in the D test suite and for which no test cases exist. I find -betterC to be somewhat of a copout for avoiding the hard work of improving D's implementation. On the contrary, I view it as providing motivation for dealing with those issues. The PR above is stalled for lack of motivation. --- Another issue is asserts. -betterC redirects them to C's assert. Perhaps we should abandon D's asserts? -betterC provides motivation to examine that.
Re: D as a Better C
On Thu, Aug 24, 2017 at 08:13:29PM +0200, Iain Buclaw via Digitalmars-d-announce wrote: [...] > The GDC camp concurs with the sentiment of betterC being a waste of > time. My particular stance on the matter is that it should not be an > all or nothing switch, granular control is fine. The compiler should > (and can!) produce a very small footprint whilst using the expressive > richness of the language. > > For instance, a D project targeting STM board, makes heavy use of > classes and templates, resultant code segment is 3k. > > https://github.com/JinShil/stm32f42_discovery_demo#the-good > > I quote the author here that when building the project, there is: > > """ > No Stinking -betterC. If you don't want the overhead of a certain > feature of D, don't use it. -betterC is just a synonymn for -worseD. > """ To be fair, though, the above-mentioned project did have to create a stub druntime in order to get things to work. Not everyone may have the know-how required to construct a minimal druntime that works for their purposes. T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Re: Article: Writing Julia style multiple dispatch code in D
On Thursday, 24 August 2017 at 17:20:20 UTC, data pulverizer wrote: In any case, Jean-Louis Leroy did some magic recently to support multiple dynamic dispatch in D. :) http://forum.dlang.org/post/cigbfrgipbokyetsk...@forum.dlang.org I haven't seen this. I'll have to get back to you when I have read it. I wouldn't expect it to be that useful for univariate distributions as you wouldn't have much reason to have a different implmentation at run-time. However, it might be useful with multivariate distributions for the same reason that you might want to specialize matrix math by the size of the matrix.
Re: Article: Writing Julia style multiple dispatch code in D
On Thursday, 24 August 2017 at 16:10:32 UTC, data pulverizer wrote: Hi all, I have written an article about writing Julia style multiple dispatch code in D (https://github.com/dataPulverizer/dispatch-it-like-julia). I am hoping that it is appropriate for the D blog. Reviews please. Many Thanks! I think at one point I had actually suggested that dstats or something be re-written in a Julia-like way (before I realized how much work that would be!). It looks very pretty. Nevertheless, you might be re-inventing the wheel a bit if you want to build a whole library in this style. My recommendation would be to write a front-end for the dstats.distrib and dstats.random submodules in this style. That way you won't need to re-write all the functions, you can just call ones from dstats that have already been tested. More generally, I prefer the structs because they don't rely on the garbage collector, but the class/interface version is prettier. Atila's concepts library has implements, which you might find helpful. I have gently nudged him to work on something that also can tell if a type is a subtype of another type more generally (like a struct being a subtype of another struct). I think this would really be a good use case for that functionality.
Re: D as a Better C
On 23 August 2017 at 19:44, Jonathan M Davis via Digitalmars-d-announce wrote: > On Wednesday, August 23, 2017 13:12:04 Mike Parker via Digitalmars-d- > announce wrote: >> To coincide with the improvements to -betterC in the upcoming DMD >> 2.076, Walter has published a new article on the D blog about >> what it is and why to use it. A fun read. And I'm personally >> happy to see the love this feature is getting. I have a project >> I'd like to use it with if I can ever make the time for it! >> >> The blog: >> >> https://dlang.org/blog/2017/08/23/d-as-a-better-c/ >> >> Reddit: >> https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/ > > I confess that I tend to think of betterC as a waste of time. Clearly, there > are folks who find it useful, but it loses so much that I see no point in > using it for anything unless I have no choice. As long as attempts to > improve it don't negatively impact normal D, then I don't really care what > happens with it, but it's clearly not for me. > > And it _is_ possible to use full-featured D from C/C++ when D does not > control main. It's just more of a pain. > It's getting better, there are certainly some tough topics that need to be addressed in the compiler implementation. The GDC camp concurs with the sentiment of betterC being a waste of time. My particular stance on the matter is that it should not be an all or nothing switch, granular control is fine. The compiler should (and can!) produce a very small footprint whilst using the expressive richness of the language. For instance, a D project targeting STM board, makes heavy use of classes and templates, resultant code segment is 3k. https://github.com/JinShil/stm32f42_discovery_demo#the-good I quote the author here that when building the project, there is: """ No Stinking -betterC. If you don't want the overhead of a certain feature of D, don't use it. -betterC is just a synonymn for -worseD. """
Re: Article: Writing Julia style multiple dispatch code in D
On Thursday, 24 August 2017 at 17:01:38 UTC, Ali Çehreli wrote: This works only with compile-time dispatch, right? Yes ... Does Julia support dynamic multiple dispatch? Okay Julia is my second favourite language next to D and one of it's cool features is that even though it is a dynamic programming language, methods are compiled for specific call signatures on first use of the function. So officially Julia does dynamic dispatch, but it pre-compiles function signatures. In any case, Jean-Louis Leroy did some magic recently to support multiple dynamic dispatch in D. :) http://forum.dlang.org/post/cigbfrgipbokyetsk...@forum.dlang.org I haven't seen this. I'll have to get back to you when I have read it. Thanks
Re: D as a Better C
On Thursday, 24 August 2017 at 03:31:02 UTC, Swoorup Joshi wrote: On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis wrote: On Wednesday, August 23, 2017 13:12:04 Mike Parker via Digitalmars-d- announce wrote: [...] I confess that I tend to think of betterC as a waste of time. Clearly, there are folks who find it useful, but it loses so much that I see no point in using it for anything unless I have no choice. As long as attempts to improve it don't negatively impact normal D, then I don't really care what happens with it, but it's clearly not for me. And it _is_ possible to use full-featured D from C/C++ when D does not control main. It's just more of a pain. - Jonathan M Davis Totally agree with this. I disagree, I believe BetterC is worth the time.
Re: Article: Writing Julia style multiple dispatch code in D
On Thursday, 24 August 2017 at 16:41:54 UTC, David Gileadi wrote: Very interesting! Thank you I have a couple suggestions: for newbies like me, it would be nice to include a short explanation of multiple dispatch, and maybe a link to a longer description. Wikipedia's description of multiple dispatch is pretty good, I'll include it and add a short description. ... Also it wouldn't hurt to include a short excerpt of how this code would look in Julia, along with the D examples. I included a link to Julia package as an example but I could add a short snippet as illustration. Finally, I wonder if Discrete and Continuous couldn't be user-defined attributes. They could but the code closely models Julia's typing system, but UDAs could add good usability to this style of programming as well.
Re: Article: Writing Julia style multiple dispatch code in D
On 08/24/2017 09:10 AM, data pulverizer wrote: Hi all, I have written an article about writing Julia style multiple dispatch code in D (https://github.com/dataPulverizer/dispatch-it-like-julia). I am hoping that it is appropriate for the D blog. Reviews please. Many Thanks! This works only with compile-time dispatch, right? Does Julia support dynamic multiple dispatch? In any case, Jean-Louis Leroy did some magic recently to support multiple dynamic dispatch in D. :) http://forum.dlang.org/post/cigbfrgipbokyetsk...@forum.dlang.org Ali
Re: Article: Writing Julia style multiple dispatch code in D
On 8/24/17 9:10 AM, data pulverizer wrote: Hi all, I have written an article about writing Julia style multiple dispatch code in D (https://github.com/dataPulverizer/dispatch-it-like-julia). I am hoping that it is appropriate for the D blog. Reviews please. Many Thanks! Very interesting! I have a couple suggestions: for newbies like me, it would be nice to include a short explanation of multiple dispatch, and maybe a link to a longer description. Also it wouldn't hurt to include a short excerpt of how this code would look in Julia, along with the D examples. Finally, I wonder if Discrete and Continuous couldn't be user-defined attributes.
Article: Writing Julia style multiple dispatch code in D
Hi all, I have written an article about writing Julia style multiple dispatch code in D (https://github.com/dataPulverizer/dispatch-it-like-julia). I am hoping that it is appropriate for the D blog. Reviews please. Many Thanks!
Re: D as a Better C
On 2017-08-24 02:55, H. S. Teoh via Digitalmars-d-announce wrote: One thing that would help is if things like TypeInfo, ModuleInfo, etc., are only emitted on-demand I think that would be quite difficult if we want to keep all the existing features. Combining separate compilation, runtime reflection and similar features make it difficult to know when a Type/ModuleInfo is used. -- /Jacob Carlborg
Re: D as a Better C
On Wednesday, 23 August 2017 at 17:43:27 UTC, Steven Schveighoffer wrote: I thought "closure" means allocating the stack onto the heap so you can return the delegate with its context intact. I understood closure as capture of variables from external context. They are divided into upward closures and downward closures, the former needs heap allocation.
Re: D as a Better C
On Wednesday, 23 August 2017 at 22:45:27 UTC, sarn wrote: I haven't tried the latest iteration of betterC yet, but the longstanding problem is that the compiler generates TypeInfo instances for structs LDC doesn't generate TypeInfo for structs until it's required for some features like array comparison.
Re: Visual Studio Code code-d serve-d beta release
On Wednesday, 23 August 2017 at 20:10:01 UTC, WebFreak001 wrote: On Wednesday, 23 August 2017 at 15:41:02 UTC, Paolo Invernizzi wrote: On Saturday, 5 August 2017 at 22:43:31 UTC, WebFreak001 wrote: [...] It seems that under macOS, the linux executable is used, with a fresh install... iMac:~ pinver$ uname -a Darwin iMac.local 17.0.0 Darwin Kernel Version 17.0.0: Wed Aug 16 20:06:51 PDT 2017; root:xnu-4570.1.45~23/RELEASE_X86_64 x86_64 iMac:~ pinver$ file /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/serve-d/serve-d /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/serve-d/serve-d: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=788ec4845beac53f20ad0c0279f6b143bf9e42cc, with debug_info, not stripped Version 0.17.3 ... --- Paolo uh serve-d doesn't have any prebuilt binaries yet so that is compiled on your PC and should be correct Well, it would be really strange that dmd was able to compile and link a linux executable on my iMac, no? :-O Anyway... iMac:serve-d pinver$ pwd /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/serve-d iMac:serve-d pinver$ dub build --build=release Package xdgpaths can be upgraded from 0.2.3 to 0.2.4. Package dub can be upgraded from 1.2.1 to 1.2.2. Package libdparse can be upgraded from 0.7.0 to 0.7.1. Use "dub upgrade" to perform those changes. Performing "release" build using dmd for x86_64. eventsystem 1.1.0: building configuration "library"... dunit 1.0.14: building configuration "library"... painlesstraits 0.2.0: building configuration "library"... painlessjson 1.3.8: building configuration "library"... dub 1.2.1: building configuration "library"... libdparse 0.7.0: building configuration "library"... ../../../../../.dub/packages/libdparse-0.7.0/libdparse/src/dparse/ast.d(1346,10): Deprecation: cannot implicitly override base class method object.Object.opEquals with dparse.ast.Declaration.opEquals; add override attribute isfreedesktop 0.1.1: building configuration "library"... xdgpaths 0.2.3: building configuration "library"... standardpaths 0.7.1: building configuration "default"... workspace-d 2.10.1: building configuration "library"... ../../../../../.dub/packages/libdparse-0.7.0/libdparse/src/dparse/ast.d(1346,10): Deprecation: cannot implicitly override base class method object.Object.opEquals with dparse.ast.Declaration.opEquals; add override attribute serve-d ~master: building configuration "application"... ../../../../../.dub/packages/libdparse-0.7.0/libdparse/src/dparse/ast.d(1346,10): Deprecation: cannot implicitly override base class method object.Object.opEquals with dparse.ast.Declaration.opEquals; add override attribute Linking... iMac:serve-d pinver$ file serve-d serve-d: Mach-O 64-bit executable x86_64 Now... iMac:bin pinver$ file /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/workspace-d /Users/pinver/.vscode/extensions/webfreak.code-d-beta-0.17.3/bin/workspace-d: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=5cb6f08ed280d886418aeeeb4332a380d9cc44aa, not stripped Again linux, there's no source code in the extension, so, I think that this binary was installed directly along with the plugin... Can you check? If I want to build it, what repo and revision should I use? --- /Paolo