On Tuesday, 21 February 2017 at 14:17:39 UTC, Steve Biedermann wrote:
> On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
>> [...]
>
> I'm using D for small tools for about a year now and I never had to mess with GC. Most of the tools don't need to work on GBs of data and performance has always been good enough.
>
> [...]

I would upvote you if I could! :-) ... that's not only an interesting read, but also fodder for mini-projects of my own!

On Monday, 20 February 2017 at 17:43:22 UTC, Ali Çehreli wrote:
> On 02/20/2017 07:00 AM, timmyjose wrote:
>
> > slice can be spawned off into a brand new array upon
> assigning data to
> > it (in the book "Learning D", which I find very nice so far).
>
> It's not assigning data to a slice, but adding elements to it: It *may* spawn off a new array. You can use .capacity to see whether that will be the case:
>
>   http://ddili.org/ders/d.en/slices.html#ix_slices..capacity
>
> Related to your earlier question on multi-dimensional array syntax, which you seem to find "brilliant": :)
>
>
> http://ddili.org/ders/d.en/slices.html#ix_slices.multi-dimensional%20array
>
> Also, there is the following article which explains the inner workings of slices:
>
>   https://dlang.org/d-array-article.html
>
> Ali

You're absolutely right! It was badly worded on my part.  And thanks for the links, they really do help! :-)

On Monday, 20 February 2017 at 17:36:32 UTC, H. S. Teoh wrote:
> On Mon, Feb 20, 2017 at 03:00:05PM +0000, timmyjose via Digitalmars-d-learn wrote: [...]
>> Just one question about the compilers though - I read on the Wiki that there are three main compiler distros - dmd, ldc, and gdc. I code primarily on a mac, and I have installed both dmd and ldc. A lot of the flags appears to be similar, and for my small programs, compilation and execution speed appeared to be almost identical. However, the book suggested using dmd for dev and probably ldc/gdc for releases. Is this really followed that much in practice, or should I prefer dmd?
>
> Personally, I use dmd git HEAD for 90% of my D projects, because (1) I'm such a sucker for the latest and greatest features, bugfixes, language changes, etc., and (2) I occasionally contribute to the compiler toolchain (mainly Phobos, sometimes druntime or dmd itself) and it's much easier to debug something I use on a regular basis and not have to switch to a different version or waste time chasing down a compiler bug that's already been fixed in git HEAD.

Thank you, that's great to hear! I have installed both dmd and ldc on my mac box and am experimenting with both as well :-)

> However, when I need performant code, I pull up my trusty, rusty old gdc (which, unfortunately, tends to be about a version or two behind the main dmd release -- I believe Iain is working on improving this, though). In spite of Walter being a renowned compiler genius, he simply has too many things on his plate and working on the optimizer hasn't been a high priority, so gdc's optimizer easily beats dmd (sometimes by a long stretch).  Don't get me wrong; for your average desktop application, dmd output is more than good enough. It only really matters when you're dealing with CPU-intensive performance-critical things like maintaining framerate in a complex game engine, or real-time software where somebody dies if the program fails to respond within a 10ms margin, or when you're trying to solve a PSPACE-complete exponential problem where a 20ms difference in inner loop performance could mean the difference between getting a result next week vs. next year (or next millenium).

That makes a whole lot of sense.

> But if you're a stickler for high-performance code, gdc's optimizer far outstrips dmd's in just about every way that I can think of -- more aggressive inlining, better loop optimization, better codegen in general.  And reputedly ldc has comparable performance gains over dmd as well, so that's another option.  The only downside is that gdc releases are tied to the gcc release cycle, so it tends to be about a version or two behind mainline dmd, and ldc is about a version behind AFAIK.  But as far as the basics of D are concerned, that shouldn't make a big difference, unless you're unlucky enough to be bitten by a compiler bug that has no workaround and that's only fixed in the latest dmd release. Thankfully, though, compiler bugs of that sort have been quite rare (and getting rarer with recent releases).
>
>
>> One more thing I noticed when I looked into the executable file (using "nm -gU" on my mac) is that I found two interesting symbols - _main and _Dmain.  On Rust, for instance, the main function got turned into _main, so I couldn't use a main in the C code that I was trying to interop with from my Rust code. In this case, does the same restriction apply (I am still way too far from dabbling in interop in D as yet! :-)). I mean, suppose I write some sample code in C, and I have a local main function to test the code out locally, will I have to comment that out when invoking that library from D, or can I keep that as is?

> _Dmain is the entry point of your D program, and is only emitted if you have a main() function in your D code.  In that case, you'll want the druntime version of _main (which does a bunch of setup necessary before _Dmain is called).

Ah, I see. Now I understand why those two symbols are there!

>But if you're calling D from C code, i.e., the C code defines main(),
> then you wouldn't also write a main() in D code (obviously -- I hope), though you *would* need to call a druntime hook to initialize some D runtime things needed before you call any D code. (Sorry, can't remember the exact calls off the top of my head, but it's a simple matter of calling an init routine or two at startup, before invoking any D code, then calling the cleanup routine at the end before the program exits. Pretty standard stuff.)
>
>
> T

Got it! So you're saying that in case I want to call D code from C, then I do need to take care of some initialisation for the D runtime so that I can call the D library's code. That makes sense indeed.

On 02/21/2017 09:13 AM, timmyjose wrote:
> On Tuesday, 21 February 2017 at 14:17:39 UTC, Steve Biedermann wrote:
>> On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
>>> [...]
>>
>> I'm using D for small tools for about a year now and I never had to
>> mess with GC. Most of the tools don't need to work on GBs of data and
>> performance has always been good enough.
>>
>> [...]
>
> I would upvote you if I could! :-) ... that's not only an interesting
> read, but also fodder for mini-projects of my own!

Making sure that you've seen the link that sarn had posted earlier in this thread:

> https://forum.dlang.org/thread/o6c9tj$2bdp$1@digitalmars.com
> (Silicon Valley D Meetup - January 26, 2017 - "High Performance Tools in D" by Jon Degenhardt)

Jon Degenhardt has been writing multiple times faster running tools just by (almost) casual D coding. (Hopefully he will write a blog post about his experiences soon.)

Ali

On Tuesday, 21 February 2017 at 19:55:37 UTC, Ali Çehreli wrote:
> On 02/21/2017 09:13 AM, timmyjose wrote:
>> On Tuesday, 21 February 2017 at 14:17:39 UTC, Steve Biedermann wrote:
>>> On Saturday, 18 February 2017 at 20:15:55 UTC, timmyjose wrote:
>>>> [...]
>>>
>>> I'm using D for small tools for about a year now and I never had to
>>> mess with GC. Most of the tools don't need to work on GBs of data and
>>> performance has always been good enough.
>>>
>>> [...]
>>
>> I would upvote you if I could! :-) ... that's not only an interesting
>> read, but also fodder for mini-projects of my own!
>
> Making sure that you've seen the link that sarn had posted earlier in this thread:
>
> > https://forum.dlang.org/thread/o6c9tj$2bdp$1@digitalmars.com
> > (Silicon Valley D Meetup - January 26, 2017 - "High
> Performance Tools in D" by Jon Degenhardt)
>
> Jon Degenhardt has been writing multiple times faster running tools just by (almost) casual D coding. (Hopefully he will write a blog post about his experiences soon.)
>
> Ali

I had a chance to get around to watching the video at last. Very interesting, and grand job on the interview. Things like these will definitely help increase the community. More and more people should start creating content (no matter how small or big), and that will pique people's curiosity! :-)

On Tuesday, 21 February 2017 at 17:13:30 UTC, timmyjose wrote:
> I would upvote you if I could! :-) ... that's not only an interesting read, but also fodder for mini-projects of my own!

If you need more details about a specific topic, just post it in the forum and we will try to help :)

If you want some sourcecode to look at you can write me a mail and I can give you access to some of my tools. The ones which are stored on bitbucket are pretty simple to understand, but not quite ready for public release (no polishing etc.).

On Wednesday, 22 February 2017 at 07:48:42 UTC, Steve Biedermann wrote:
> On Tuesday, 21 February 2017 at 17:13:30 UTC, timmyjose wrote:
>> I would upvote you if I could! :-) ... that's not only an interesting read, but also fodder for mini-projects of my own!
>
> If you need more details about a specific topic, just post it in the forum and we will try to help :)
>
> If you want some sourcecode to look at you can write me a mail and I can give you access to some of my tools. The ones which are stored on bitbucket are pretty simple to understand, but not quite ready for public release (no polishing etc.).

Thanks, Steve. That'd be great! I will surely take you up on that offer. Right now I'm working through "Learning D", and loving every bit of it! From there I plan to get right down to coding on some small but interesting projects, and any help I can get would be most welcome! :-)