Re: D as a Better C
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.
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/ Thanks for this feature! Looking forward to see its future --Ilya
Re: D as a Better C
On Thu, Aug 24, 2017 at 12:35:22AM +, Michael V. Franklin via Digitalmars-d-announce 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. I find -betterC to be somewhat of a copout for > avoiding the hard work of improving D's implementation. [...] One thing that would help is if things like TypeInfo, ModuleInfo, etc., are only emitted on-demand, or if they are stored as weak symbols in the object file so that the linker can just omit them if they are never referenced. Ideally, the GC would also be on-demand, but it's currently too tightly integrated with druntime for this to be possible. At least, it would take a huge amount of effort to make it work. Similarly, thread-related stuff might be difficult to make optional, since the D startup code is dependent on it. Other smaller things in druntime like string switches, array comparison functions, etc., could possibly also be optionally included, but then you'll need to link (parts of) druntime. It will be more troublesome, but within the realm of possibility, I think. I, for one, would be happier if D's features are more pay-as-you-go so that simpler programs don't have to pull in a whole bunch of executable bloat that's not actually going to be used. T -- Let's eat some disquits while we format the biskettes.
Re: D as a Better C
On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis 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. I'm somewhat in agreement here. I wouldn't call it a "waste of time", but I would prefer refactoring D's implementation to make using full-featured D from C/C++ less of a pain. I fear, however, that -betterC will be the favored excuse for not pursuing or prioritizing such improvements. 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. I find -betterC to be somewhat of a copout for avoiding the hard work of improving D's implementation. Mike
Re: D as a Better C
On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis wrote: I confess that I tend to think of betterC as a waste of time. The overwhelming majority of programmers don't need betterC. At all. But today we live in a world where practically everything just builds on top of C, and we keep seeing how that goes wrong. I think Rust and betterC D are the best candidates we've got for replacing C everywhere C is used.
Re: D as a Better C
On Wednesday, 23 August 2017 at 16:17:57 UTC, SrMordred wrote: No structs in -betterC ??? I haven't tried the latest iteration of betterC yet, but the longstanding problem is that the compiler generates TypeInfo instances for structs, and TypeInfos are classes, which inherit from Object, which are implemented in the D runtime. If you're using the current release of D, the workarounds are to include an implementation of Object so that classes work, or hack out the TypeInfo at link time.
Re: D as a Better C
On Wednesday, 23 August 2017 at 17:43:27 UTC, Steven Schveighoffer wrote: On 8/23/17 11:59 AM, Walter Bright wrote: On 8/23/2017 7:37 AM, Steven Schveighoffer wrote: How do dynamic closures work without the GC? They don't allocate the closure on the GC heap. (Or do I have static/dynamic closures backwards?) I thought "closure" means allocating the stack onto the heap so you can return the delegate with its context intact. From https://en.wikipedia.org/wiki/Closure_(computer_programming) : "A language implementation cannot easily support full closures if its run-time memory model allocates all automatic variables on a linear stack. In such languages, a function's automatic local variables are deallocated when the function returns. However, a closure requires that the free variables it references survive the enclosing function's execution. Therefore, those variables must be allocated so that they persist until no longer needed, typically via heap allocation, rather than on the stack, and their lifetime must be managed so they survive until all closures referencing them have are no longer in use." Right, so if we wanted to support closures in betterC (we don't now, as my earlier example shows), they'd need a separate lifetime management implementation. The two straightforward ones are either disable copying of closures in betterC (only moving them), so a single ownership model of their heap allocated context pointer is possible (deallocating the memory once the closure is destroyed), or make them reference counted. The first has the disadvantage that you can't have two closures point to the same heap context (though to be honest, I haven't seen a codebase so far that actually uses that), but it should be trivial to implement. The RC variant is more complex (it would require an analysis if reference cycles can occur), but I think this might be one of the cases where RC is the right solution (and we might even consider using RC in normal D as well, if it works sanely).
Re: Visual Studio Code code-d serve-d beta release
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
Re: D as a Better C
On Wednesday, 23 August 2017 at 17:39:00 UTC, Walter Bright wrote:
On 8/23/2017 10:26 AM, jmh530 wrote:
Am I correct that betterC requires main to be extern(C) and
must act like a C main (i.e. no void return)?
Yes.
This might be added to
http://dlang.org/dmd-windows.html#switch-betterC
or
http://dlang.org/spec/betterc.html
Is that something that can be changed in the future?
Yes, but I don't see a need for it.
Fair enough. A version statement could handle it
version(BetterC)
{
extern(C) int main()
{
callRealMain();
}
}
else
{
void main()
{
callRealMain();
}
}
Re: D as a Better C
On 8/23/17 11:59 AM, Walter Bright wrote: On 8/23/2017 7:37 AM, Steven Schveighoffer wrote: How do dynamic closures work without the GC? They don't allocate the closure on the GC heap. (Or do I have static/dynamic closures backwards?) I thought "closure" means allocating the stack onto the heap so you can return the delegate with its context intact. From https://en.wikipedia.org/wiki/Closure_(computer_programming) : "A language implementation cannot easily support full closures if its run-time memory model allocates all automatic variables on a linear stack. In such languages, a function's automatic local variables are deallocated when the function returns. However, a closure requires that the free variables it references survive the enclosing function's execution. Therefore, those variables must be allocated so that they persist until no longer needed, typically via heap allocation, rather than on the stack, and their lifetime must be managed so they survive until all closures referencing them have are no longer in use." -Steve
Re: D as a Better C
On 8/23/2017 10:17 AM, Kagamin wrote: Also how assert failure works in C? It calls the C assert failure function.
Re: D as a Better C
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. - Jonathan M Davis
Re: D as a Better C
On 8/23/2017 10:26 AM, jmh530 wrote: Am I correct that betterC requires main to be extern(C) and must act like a C main (i.e. no void return)? Yes. Is that something that can be changed in the future? Yes, but I don't see a need for it.
Re: D as a Better C
On 8/23/17 11:52 AM, Walter Bright wrote: On 8/23/2017 7:24 AM, Steven Schveighoffer wrote: Looks like there are some outstanding requests to be fulfilled before it's pulled. I don't agree that the requests improve matters. You may want to mention that in the PR. Right now it just looks like you haven't seen or responded to the requests. -Steve
Re: D as a Better C
On 8/23/17 11:56 AM, Walter Bright wrote: On 8/23/2017 7:10 AM, Steven Schveighoffer wrote: Nope. A ModuleInfo is generated, as well as FMB/FM/FME sections. Those sections may not work with the C runtime. My point was simply that your small example doesn't cause any runtime or link time errors. You need something more complicated to require betterC. Not sure if ModuleInfo is generated. IIRC, Martin made it so it's not if no usage of the ModuleInfo is apparent. Yes, adding a struct causes link errors, but not because of ModuleInfo, it's because of the expected TypeInfo. -Steve
Re: D as a Better C
On Wednesday, 23 August 2017 at 14:01:30 UTC, jmh530 wrote: Great piece. It might be useful to beef up the documentation on some of the things that betterC changes. For instance, here http://dlang.org/dmd-windows.html#switch-betterC links to TypeInfo, which has like one line of explanation of what it's for, and ModuleInfo isn't linked to at all (and I'm still a little unclear on what that does). Am I correct that betterC requires main to be extern(C) and must act like a C main (i.e. no void return)? Is that something that can be changed in the future? For instance, the simplest change would be if the compiler knows that its betterC, then it can insert extern(C) to main. A second adjustment could potentially to re-write D's void main's to int and add in a return. The first seems like a good idea superficially, but I'm not 100% on the second.
Re: D as a Better C
On Wednesday, 23 August 2017 at 14:00:34 UTC, Walter Bright wrote: One of the reasons people use C is to get that small footprint. This has been a large barrier to C programs making use of D. Not a better C, but intermediate D has small footprint for me too. 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 8/23/2017 6:12 AM, Mike Parker wrote: 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/ Now on the front page of news.ycombinator.com !
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. I like this concept of "upward compatibility," -- although opposed to backward it should be phrased "forward." Will share also this one on LinkedIn... I see D has official account on Facebook, Twitter, Reddit... No interest in LinkedIn? I think it can also be a good promotion platform for D.
Re: D as a Better C
On Wednesday, 23 August 2017 at 16:17:57 UTC, SrMordred wrote: On Wednesday, 23 August 2017 at 15:53:11 UTC, Walter Bright wrote: On 8/23/2017 7:10 AM, Steven Schveighoffer wrote: It's only if you do something that needs the runtime, such as static ctors, or use the GC. Or use asserts, or even declare a struct. No structs in -betterC ??? IIUC, Steven's question was about the need for the `-betterC` switch - in his small example there was no need for it. Walter pointed out that without -betterC using structs cause link-time references to druntime, which are avoided by the use of the `-betterC` switch. Though, one particular thing that doesn't work in `-betterC` w.r.t. structs is RAII. You can still call manually the destructor, but that's a crude hack. Work on RAII for `-betterC` is work in progress.
Re: D as a Better C
On Wednesday, 23 August 2017 at 15:53:11 UTC, Walter Bright wrote: On 8/23/2017 7:10 AM, Steven Schveighoffer wrote: It's only if you do something that needs the runtime, such as static ctors, or use the GC. Or use asserts, or even declare a struct. No structs in -betterC ???
Re: D as a Better C
On 8/23/2017 7:37 AM, Steven Schveighoffer wrote: How do dynamic closures work without the GC? They don't allocate the closure on the GC heap. (Or do I have static/dynamic closures backwards?)
Re: D as a Better C
On 8/23/2017 8:05 AM, John Colvin wrote: "D polymorphic classes will not, as they rely on the garbage collector." They do? Don't have to allocate classes on the GC heap. Using them without the GC is a fairly advanced technique, and I don't want to deal with people writing: C c = new C(); and complaining that it doesn't work.
Re: D as a Better C
On 8/23/2017 7:10 AM, Steven Schveighoffer wrote: Nope. A ModuleInfo is generated, as well as FMB/FM/FME sections. Those sections may not work with the C runtime.
Re: D as a Better C
On 8/23/2017 7:10 AM, Steven Schveighoffer wrote: It's only if you do something that needs the runtime, such as static ctors, or use the GC. Or use asserts, or even declare a struct.
Re: D as a Better C
On 8/23/2017 7:24 AM, Steven Schveighoffer wrote: Looks like there are some outstanding requests to be fulfilled before it's pulled. I don't agree that the requests improve matters.
Re: Visual Studio Code code-d serve-d beta release
On Saturday, 5 August 2017 at 22:43:31 UTC, WebFreak001 wrote: You might remember the blog post from a while back about workspace-d and serve-d, I just released a beta version on the visual studio marketplace that allows you to try out the latest features of serve-d. Note that this version might easily break in the future, but for the next few days I am trying to gain some feedback. If you are a user of code-d and if you want to try out the new version please uninstall code-d and install code-d-beta (https://marketplace.visualstudio.com/items?itemName=webfreak.code-d-beta, it's version 0.16.1) and just try to use it. [...] 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
Re: D as a Better C
On Wednesday, 23 August 2017 at 15:17:31 UTC, Moritz Maxeiner
wrote:
On Wednesday, 23 August 2017 at 14:37:19 UTC, Steven
Schveighoffer wrote:
On 8/23/17 9:12 AM, 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/
How do dynamic closures work without the GC?
Nice article, BTW.
-Steve
They don't (right now, using dmd ~master), because they depend
on druntime:
[...]
Sorry, I screwed up when pasting. Here's what I meant to post:
--- a.c ---
#include
#include
uint32_t foo();
int main(int argc, char** argv)
{
uint32_t x = foo();
printf("%d\n", x);
return 0;
}
---
--- b.d ---
auto test()
{
uint i = 42;
return () {
return i;
};
}
$ dmd -c -betterC b.d
$ gcc a.c b.d
Undefined symbols for architecture x86_64:
"__d_allocmemory", referenced from:
_D1b4testFNaNbNfZDFNaNbNiNfZk in b.o
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/ nice article, however very unfortunate introduction for the ADHD Generation as you start reading and you get put of by historical disabilities of D that are not true anymore. you may want to edit that and add the "until now" beforehand ;)
Re: D as a Better C
On Wednesday, 23 August 2017 at 14:37:19 UTC, Steven
Schveighoffer wrote:
On 8/23/17 9:12 AM, 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/
How do dynamic closures work without the GC?
Nice article, BTW.
-Steve
They don't (right now, using dmd ~master), because they depend on
druntime:
--- a.c ---
#include
#include
uint32_t foo();
int main(int argc, char** argv)
{
uint32_t x = foo();
printf("%d\n", x);
}
---
--- b.d ---
auto test()
{
uint i = 42;
return () {
return i;
};
}
oo()
{
auto x = test();
return x();
}
---
$ dmd -c -betterC b.d
$ gcc a.c b.d
Undefined symbols for architecture x86_64:
"__d_allocmemory", referenced from:
_D1b4testFNaNbNfZDFNaNbNiNfZk in b.o
ld: symbol(s) not found for architecture x86_64extern(C) uint
foo()
{
auto x = test();
return x();
}
---
$ dmd -c -betterC b.d
$ gcc a.c b.d
Undefined symbols for architecture x86_64:
"__d_allocmemory", referenced from:
_D1b4testFNaNbNfZDFNaNbNiNfZk in b.o
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/ "D polymorphic classes will not, as they rely on the garbage collector." They do? Don't have to allocate classes on the GC heap.
Re: dub zsh completion
On Tuesday, August 22, 2017 22:35:53 Johannes Loher via Digitalmars-d- announce wrote: > I created a zsh completion script for dub. It is not perfect, but > it does many things well already. You can find it here: > https://github.com/ghost91-/dub-zsh-completion. > > I have seen that bash and fish completion scripts are included in > the dub github repo. If people are interested in this, I could > create a pull request to also add the zsh completion script. > > I hope this helps some people :) Wait, you mean that there are shells other than zsh? ;) Thanks. I'll have to check this out. - Jonathan M Davis
Re: D as a Better C
On 8/23/17 9:12 AM, 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/ How do dynamic closures work without the GC? Nice article, BTW. -Steve
Re: D as a Better C
On Wednesday, 23 August 2017 at 14:00:34 UTC, Walter Bright wrote:
On 8/23/2017 6:28 AM, Moritz Maxeiner wrote:
I've been mixing C and full D for a while now (on Linux) by
either having the main C program call rt_init/rt_term directly
(if druntime is linked in when building a mixed C/D
application), or have Runtime.initialize/Runtime.terminate be
called from D via some plugin_load/plugin_unload functionality
when using D shared libraries.
Why is this not considered practical?
Because in order to add a D function as trivial as:
int foo() { return 3; }
to a C program, now the C program has to link to druntime, and
the program no longer has a small footprint. One of the reasons
people use C is to get that small footprint. This has been a
large barrier to C programs making use of D.
Thank you, are there other factors involved, or is it only
impractical for people who require minimal application size /
memory footprint, then?
Re: D as a Better C
On 8/23/17 10:11 AM, Walter Bright wrote: On 8/23/2017 7:01 AM, jmh530 wrote: ModuleInfo isn't linked to at all (and I'm still a little unclear on what that does). That's because ModuleInfo doesn't appear in the online documentation due to having a malformed Ddoc comment. I fixed it here: https://github.com/dlang/druntime/pull/1906 but nobody has pulled it. Looks like there are some outstanding requests to be fulfilled before it's pulled. -Steve
Re: D as a Better C
On Wednesday, 23 August 2017 at 14:01:30 UTC, jmh530 wrote: 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/ Great piece. It might be useful to beef up the documentation on some of the things that betterC changes. For instance, here http://dlang.org/dmd-windows.html#switch-betterC links to TypeInfo, which has like one line of explanation of what it's for, and ModuleInfo isn't linked to at all (and I'm still a little unclear on what that does). Walter has made a PR to improve the ModuleInfo documentation: https://github.com/dlang/druntime/pull/1906
Re: D as a Better C
On 8/23/2017 7:01 AM, jmh530 wrote: ModuleInfo isn't linked to at all (and I'm still a little unclear on what that does). That's because ModuleInfo doesn't appear in the online documentation due to having a malformed Ddoc comment. I fixed it here: https://github.com/dlang/druntime/pull/1906 but nobody has pulled it.
Re: D as a Better C
On 8/23/17 10:00 AM, Walter Bright wrote:
On 8/23/2017 6:28 AM, Moritz Maxeiner wrote:
Interesting article, though one thing that I'm confused by is
Hence D libraries remain inaccessible to C programs, and chimera
programs (a mix of C and D) are not practical. One cannot
pragmatically “try out” D by add D modules to an existing C program.
I've been mixing C and full D for a while now (on Linux) by either
having the main C program call rt_init/rt_term directly (if druntime
is linked in when building a mixed C/D application), or have
Runtime.initialize/Runtime.terminate be called from D via some
plugin_load/plugin_unload functionality when using D shared libraries.
Why is this not considered practical?
Because in order to add a D function as trivial as:
int foo() { return 3; }
to a C program, now the C program has to link to druntime, and the
program no longer has a small footprint. One of the reasons people use C
is to get that small footprint. This has been a large barrier to C
programs making use of D.
Nope.
Stevens-MacBook-Pro:testd steves$ cat testdfunc.d
extern(C) int foo() { return 3; }
Stevens-MacBook-Pro:testd steves$ cat testdfunc_c.c
#include
extern int foo();
int main()
{
printf("%d\n", foo());
}
Stevens-MacBook-Pro:testd steves$ dmd -c testdfunc.d
Stevens-MacBook-Pro:testd steves$ gcc -o testdfunc testdfunc_c.c testdfunc.o
Stevens-MacBook-Pro:testd steves$ ./testdfunc
3
It's only if you do something that needs the runtime, such as static
ctors, or use the GC.
-Steve
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/ Great piece. It might be useful to beef up the documentation on some of the things that betterC changes. For instance, here http://dlang.org/dmd-windows.html#switch-betterC links to TypeInfo, which has like one line of explanation of what it's for, and ModuleInfo isn't linked to at all (and I'm still a little unclear on what that does).
Re: D as a Better C
On 8/23/2017 6:28 AM, Moritz Maxeiner wrote:
Interesting article, though one thing that I'm confused by is
Hence D libraries remain inaccessible to C programs, and chimera programs (a
mix of C and D) are not practical. One cannot pragmatically “try out” D by
add D modules to an existing C program.
I've been mixing C and full D for a while now (on Linux) by either having the
main C program call rt_init/rt_term directly (if druntime is linked in when
building a mixed C/D application), or have Runtime.initialize/Runtime.terminate
be called from D via some plugin_load/plugin_unload functionality when using D
shared libraries.
Why is this not considered practical?
Because in order to add a D function as trivial as:
int foo() { return 3; }
to a C program, now the C program has to link to druntime, and the program no
longer has a small footprint. One of the reasons people use C is to get that
small footprint. This has been a large barrier to C programs making use of D.
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/ Interesting article, though one thing that I'm confused by is Hence D libraries remain inaccessible to C programs, and chimera programs (a mix of C and D) are not practical. One cannot pragmatically “try out” D by add D modules to an existing C program. I've been mixing C and full D for a while now (on Linux) by either having the main C program call rt_init/rt_term directly (if druntime is linked in when building a mixed C/D application), or have Runtime.initialize/Runtime.terminate be called from D via some plugin_load/plugin_unload functionality when using D shared libraries. Why is this not considered practical?
D as a Better C
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/
Re: dub zsh completion
On Tuesday, 22 August 2017 at 22:35:53 UTC, Johannes Loher wrote: I created a zsh completion script for dub. It is not perfect, but it does many things well already. You can find it here: https://github.com/ghost91-/dub-zsh-completion. I have seen that bash and fish completion scripts are included in the dub github repo. If people are interested in this, I could create a pull request to also add the zsh completion script. I hope this helps some people :) Awesome, definitely going to check it out. I think a PR is in order. Atila
