Re: D IDE Coedit - version 3, update 3 released

[user1234 via Digitalmars-d-announce]

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

[data pulverizer via Digitalmars-d-announce]

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

[jmh530 via Digitalmars-d-announce]

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

[Michael V. Franklin via Digitalmars-d-announce]

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

[Michael V. Franklin via Digitalmars-d-announce]

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

[data pulverizer via Digitalmars-d-announce]

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

[jmh530 via Digitalmars-d-announce]

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

[WebFreak001 via Digitalmars-d-announce]

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

[jmh530 via Digitalmars-d-announce]

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

[data pulverizer via Digitalmars-d-announce]

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

[user1234 via Digitalmars-d-announce]

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

[Walter Bright via Digitalmars-d-announce]

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

[Parke via Digitalmars-d-announce]

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

[12345swordy via Digitalmars-d-announce]

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

[Walter Bright via Digitalmars-d-announce]

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

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

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

[jmh530 via Digitalmars-d-announce]

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

[jmh530 via Digitalmars-d-announce]

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

[Iain Buclaw via Digitalmars-d-announce]

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

[data pulverizer via Digitalmars-d-announce]

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

[twkrimm via Digitalmars-d-announce]

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

[data pulverizer via Digitalmars-d-announce]

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

[Ali Çehreli via Digitalmars-d-announce]

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

[David Gileadi via Digitalmars-d-announce]

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

[data pulverizer via Digitalmars-d-announce]

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

[Jacob Carlborg via Digitalmars-d-announce]

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

[Kagamin via Digitalmars-d-announce]

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

[Kagamin via Digitalmars-d-announce]

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

[Paolo Invernizzi via Digitalmars-d-announce]

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