[Semi-OT] Markdown rendering extension for Thunderbird
I use Thunderbird to read this forum and have gotten jealous of the Markdown formatting that the website supports but that Thunderbird doesn't. So I made [an extension](https://addons.thunderbird.net/en-US/thunderbird/addon/render-markdown-messages/) to render Markdown-formatted messages in Thunderbird. Unfortunately this doesn't allow sending messages with Markdown formatting from Thunderbird—that would probably belong in the [Markdown-here](https://addons.thunderbird.net/en-US/thunderbird/addon/markdown-here-revival/) extension but can't work yet because Thunderbird currently [doesn't allow modifying the content-type header](https://bugzilla.mozilla.org/show_bug.cgi?id=1717221) (bug filed by Vladimir). My extension is limited to reading Markdown-formatted messages.
Re: mir.complex
On 8/20/21 9:54 AM, Dennis wrote: On Friday, 20 August 2021 at 16:44:53 UTC, 9il wrote: Builtin complex numbers have been replaced with mir.complex in the following packages: Out of curiosity, how did std.complex fall short? Maybe it was too complex? Sorry, I'll see myself out.
Re: Interfacing D with C: Arrays and Functions (Arrays Part 2)
On 4/28/20 7:45 AM, Mike Parker wrote: I've finally gotten around to publishing the next article in my D and C series on the D blog. This is the second post about arrays, focusing on properly declaring in D functions from C that accept array parameters. The blog: https://dlang.org/blog/2020/04/28/interfacing-d-with-c-arrays-and-functions-arrays-part-two/ .. Another great article! Nit: in the following paragraph, did you really mean to say *are*? But again, even D’s safety features are 100% foolproof when calling C functions from D.
Re: dud: A dub replacement
On 11/18/19 1:19 PM, Tobias Pankrath wrote: On Monday, 18 November 2019 at 19:54:38 UTC, Russel Winder wrote: Probably yes. Though Cargo has taken many different decisions to Dub and mostly I think Cargo took better decisions. Could you elaborate a bit, please? I am not familiar with Cargo though. See also Russel's previous post on this issue [1]: Go and Rust emphasised using Git, Mercurial, and Breezy repositories as packages from the outset. Go chose not to add a central repository, Rust chose to add one. Rust's choice was the correct one for supporting developers. In hindsight, Go has had problems with packages from the outset based on the initial workspace model. Slowly over the decade Go is finding ways forward. Rust got it right from the beginning, once they had stripped down the standard library and emphasised use of the central repository – if only Phobos could be stripped right back to the absolute necessary and everything else provided via the central repository. Obviously not all is good in Rust-land, just as with Python and PyPI, the central repository is not curated, and this leads to horrible messes. Ceylon got this more right, but it is a language few have heard of and even fewer use. Dub does not allow for use of Git, Mercurial, or Breezy repositories only the uncurated (and therefore potentially problematic) central repository. OK so you can do Git checkouts as a separate activity and use local filestore references, but this is not feasible for packages in the central repository. Dub builds packages to a location outside the project being worked on. Cargo pulls sources to such a central non-project place and then compiles into a project specific location. Dub tries to store all compiled version out of project in the same area as the sources. Does this matter? Isn't Dub making things easier to share? Sort of, sort of, and no. Dub stores all compilations, but hides them and presents only the last compilation easily. This makes things hard to work with for non-Dub tooling. Cargo makes it a lot easier, at the expense of lack of sharing but always compiling everything into the project area. Cargo uses TOML, Dub uses SDL (or if you are masochistic JSON). 'nuff said. QED. Dub seems to have become the de facto, and indeed de jure, standard for D build, and yet somehow Cargo is just assumed by all Rust programmers whereas Dub is a source of contention and ill-will in the D community. Dub's biggest problem is that there are many in the D community who will not use it – and they are vocal about it. The solution is not censorship, the solution is for Dub to evolve very rapidly so that these vocal people have the rug pulled from under them, i.e. their complaints become invalid. [1]: https://forum.dlang.org/post/mailman.543.1571300816.8294.digitalmar...@puremagic.com (scroll toward the end of the post)
Re: Release D 2.088.0
On 9/7/19 12:27 PM, Manu wrote: I don't know how to iterate on the docs, since they only appear from CI, and I have no idea how to create them myself :/ I don't know what the "correct" way is, but to build dlang.org locally on macOS, from the dlang.org dir I run: DIFFABLE=1 make -f posix.mak html To build phobos docs locally, from the phobos dir I run: make -f posix.mak build-html To build druntime locally, from the druntime dir I run: make -f posix.mak doc However this last one fails for me on macOS due to platform-specific compile errors: src/core/stdcpp/typeinfo.d(147): Error: static assert: "Missing std::type_info binding for this platform" In any case you'll find all the generated local docs in your dlang.org/web dir.
Re: DLS (D Language Server) v0.20
On 12/28/18 4:14 AM, Laurent Tréguier wrote: Hello, and merry Christmas! (a bit late, but whatever) This is an excellent update--the update Just Works™ with VSCode on my mac, and functions very nicely too. Thanks! I might suggest that you perhaps rename the VSCode extension to remove "VSCode" from the name (as it's redundant) and add "D Language" (because the current name makes it a bit hard to discover).
Re: The New Fundraising Campaign
On 11/10/18 9:09 AM, Mike Parker wrote: I've just published a new blog post describing our new fundraising campaign. TL;DR: We want to pay a Pull Request Manager to thin out the pull request queues and coordinate between relevant parties on newer pull requests so they don't go stale. We've launched a three-month campaign, and Nicholas Wilson has agreed to do the work. We have high hopes that this will help reduce frustration for current and future contributors. And we will be grateful for your support in making it happen. Please read the blog post for more details: https://dlang.org/blog/2018/11/10/the-new-fundraising-campaign/ For the impatient: https://www.flipcause.com/secure/cause_pdetails/NDUwNTY= Nicholas has already reduced my frustration with getting a PR merged--thanks! It was a good incentive to donate.
Re: Lost in Translation: Encapsulation
On 11/6/18 8:14 AM, Mike Parker wrote: Last week, inspired by another discussion in these forums about D's private-to-the-module form of encapsulation, I spent a few hours putting a new article together for the blog. Ali, Joakim, Nicholas helped me get it in shape. The blog: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/ Reddit: https://www.reddit.com/r/programming/comments/9up2yo/lost_in_translation_encapsulation_in_d/ As usual, an excellent bit of writing containing things I wasn't aware of. Thanks!
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
luckoverthere wrote: > On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote: >> On 10/15/2018 2:23 PM, Walter Bright wrote: >>> I'm giving a presentation at: >>> >>> http://nwcpp.org/ >>> >>> See you there! >> >> Had a nice crowd there last night. Apparently lots of people >> were interested in this topic! >> >> Video: >> https://www.youtube.com/watch?v=lbp6vwdnE0k=youtu.be >> >> Slides: http://nwcpp.org/talks/2018/code_smells.pdf > > https://www.youtube.com/watch?v=lbp6vwdnE0k#t=42m01s > > Or it's a pain in the ass to try to get more than one pull > request merged in due to lack of overseers. It's hard enough > trying to get one pull request merged in, but trying to split one > pull request into 4 and then try to micro manage it so that they > are merged in order as the changes depend on each other (eg > spelling error for a function). That becomes a nightmare when you > don't have merging permission for a repo, especially for > something like DMD where it's hard enough to get even a simple > fix through the door. I unfortunately ran into this with my make-ddoc-support-markdown PR. The original PR was considered too big, and I was asked to split it into multiple PRs against a feature branch, which would then be merged into master. I was fine with this, and started the process. It was a bit slow, but seemed like it would work. Oh, what a fool I was! When my second PR to the feature branch was approved, it couldn’t be merged because it caused unrelated errors in the tests. My best theory is that the feature branch had drifted too far away from master, and since dmd, druntime and phobos have dependencies on each other it was somehow causing the test servers to fail. There’s a bit more to the story, but it boils down to the fact that since I don’t have permissions to update the feature branch, I’m basically dead in the water. So the work is all done and ready, but I have no path forward to get it in. And it’s a bit disheartening to be foiled by the machines :)
Re: Interfacing D with C: Arrays Part 1
On 10/17/18 8:20 AM, Mike Parker wrote: I had intended to publish the next GC series post early this month, but after many revisions and discussions with a couple of reviewers, I've decided to put it on hold until something gets worked out about the conflation of destruction and finalization in D (something I'll be pushing for soon). Instead, I've gone back to an article I started writing months ago and put aside in favor of other things: my next post in the 'D and C' series. This post is the first of what will likely be three dealing with arrays (four if you count strings). It focuses primarily on declaration and initialization and is intended to be beginner friendly, assuming little or no knowledge of either C or D. The blog: https://dlang.org/blog/2018/10/17/interfacing-d-with-c-arrays-part-1/ Reddit: https://www.reddit.com/r/programming/comments/9ozhyh/interfacing_d_with_c_arrays_part_1/ Really great, thanks!
Re: Homebrew dmd betas
On 4/10/18 1:46 AM, John Colvin wrote: On Saturday, 7 April 2018 at 18:39:12 UTC, Martin Nowak wrote: First beta for the 2.079.1 patch release. Comes with a handful of fixes. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.079.1.html Please report any bugs at https://issues.dlang.org - -Martin Available now on homebrew :) [snip] I haven't tried the betas yet, but many thanks for keeping homebrew up to date with the regular releases!
Re: Documentation for any* dub package, any version
On 2/27/18 2:59 PM, Adam D. Ruppe wrote: On Tuesday, 27 February 2018 at 16:39:08 UTC, David Gileadi wrote: Markdown actually supports two kinds of links: inline links (which you describe above and I'm very happy you support) and reference links [1]. Oh, I have something similar to that too. http://dpldocs.info/experimental-docs/adrdox.syntax.html#footnotes I actually didn't realize markdown had such... mine is probably not quite compatible... but [text][text] is an uncommon enough pattern it might just be workable. I doubt I'd ever write [link][link] without a space in between... What I want to do is automatically include references for symbols in the current scope, to support links to symbols via [symbol] and [alt text][symbol]. Yeah, that might work on both generators. I hope so. I'm happy that D documentation is nicer to use. Thanks for working on it!
Re: Documentation for any* dub package, any version
On 2/27/18 3:18 PM, David Gileadi wrote: On 2/27/18 2:59 PM, Adam D. Ruppe wrote: On Tuesday, 27 February 2018 at 16:39:08 UTC, David Gileadi wrote: Markdown actually supports two kinds of links: inline links (which you describe above and I'm very happy you support) and reference links [1]. Oh, I have something similar to that too. http://dpldocs.info/experimental-docs/adrdox.syntax.html#footnotes I actually didn't realize markdown had such... mine is probably not quite compatible... but [text][text] is an uncommon enough pattern it might just be workable. I doubt I'd ever write [link][link] without a space in between... What I want to do is automatically include references for symbols in the current scope, to support links to symbols via [symbol] and [alt text][symbol]. Yeah, that might work on both generators. I hope so. I'm happy that D documentation is nicer to use. Thanks for working on it! Whoops, should have been "...D documentation is *getting* nicer to use."
Re: Documentation for any* dub package, any version
On 2/27/18 9:21 AM, Adam D. Ruppe wrote: On Tuesday, 27 February 2018 at 16:00:26 UTC, David Gileadi wrote: Out of curiosity, what prompted [symbol|alt text] instead of going with the Markdown construct of [alt text][symbol]? Well, markdown is [alt text](url), and adrdox actually DOES support that as well: http://dpldocs.info/experimental-docs/adrdox.syntax.html#markdown-style-links (I just added that last Friday though for gtkd docs compatibility!) Though it does NOT support a symbol in there, just a URL right now. Maybe I can add it, but I always start conservative - allow the least syntax with the most restrictions I can, then loosen them as I'm sure it isn't annoying. But anyway, the [symbol|alt text] comes from Wikipedia's markup actually, which is the first thing that comes to my mind to easily cross-link articles. On wikipedia, you use brackets to indicate a word as a link: `director = [[Avery Brooks]]`, for example, will link to that article. Similarly, `[[Star Trek: Deep Space Nine (season 6)|6]]` will just show the text "6", while linking to the page in there. So I took that and generalized it a bit so it supports other URLs too, then simplified it to just one set of [] instead of two. The big advantage for [] over markdown links is it is lighter syntax in the simple case: /// See also: [intersect] knows to link to the symbol `intersect`. Whereas: /// See also: [intersect](intersect) would be the equivalent markdown style, but it is repeated... so you might skip the alt text: /// See also: (intersect) but that conflicts with very common parenthetical text like "I think that's silly (sorta)..." and I wouldn't want "sorta" to be linked there! So I just went with []. Markdown actually supports two kinds of links: inline links (which you describe above and I'm very happy you support) and reference links [1]. A reference link can be like [alt text][reference] or you can do the shortcut version if your alt text is the same as the reference name: [reference]. I currently support both forms in my upcoming Markdown PR, but they only link to references that are defined elsewhere in the document, like my [1] at the bottom of this message. What I want to do is automatically include references for symbols in the current scope, to support links to symbols via [symbol] and [alt text][symbol]. [1]: http://spec.commonmark.org/0.28/#reference-link
Re: Documentation for any* dub package, any version
On 2/26/18 12:51 PM, Adam D. Ruppe wrote: ... I just have a built-in, simple, unified syntax: [symbol|alt text] where alt text is optional and symbol is looked up according to D scope rules. (you can also define custom symbols for things like author name links). I link to the source automatically too, including to the specific line of the correct overload for functions, so no need for macros to do those. Out of curiosity, what prompted [symbol|alt text] instead of going with the Markdown construct of [alt text][symbol]? I ask because if I'm able to get my Markdown support merged into DDoc, I'd like to support [symbol] and [alt text][symbol] links.
Re: Beta 2.079.0
On 2/22/18 3:30 AM, psychoticRabboit wrote: On Thursday, 22 February 2018 at 09:42:47 UTC, Atila Neves wrote: I'm going to a) never write these imports and b) pretend this feature doesn't exist. Atila what about something like this then? import std.stdio; std.conv: to, from; std.algorithm: doSomething; std.whatever; just one simple rule; multiple imports on a line are seperated with ; surely the parser or whatever it's called, could work with that clean and simple solution. Using a semicolon occurred to me too. If the feature is to be kept, this is the syntax that is easiest to read and remember for me.
Re: DConf 2018: Register Now!
On 1/31/18 3:08 PM, David Gileadi wrote: On 1/31/18 3:02 PM, Seb wrote: It was the middle of November when DConf 2018 was announced here on the DBlog in a Q & A session with Andrei Alexandrescu. Since then, the DConf train has slowly been building up steam as things have been happening behind the scenes. Now it’s full steam ahead! https://dlang.org/blog/2018/01/31/dconf-2018-register-now Reddit: https://www.reddit.com/r/programming/comments/7udoi2/registration_for_dconf_2018_is_now_open/ Broken link: the link to the "DConf 2018 venue page" needs an extra 'l' at the end, i.e. venue.htm -> venue.html Whoops, another broken link: "HLMC" links to https://dlang.org/blog/2018/01/31/dconf-2018-register-now/www.hlmc.de, but it should link to http://www.hlmc.de
Re: DConf 2018: Register Now!
On 1/31/18 3:02 PM, Seb wrote: It was the middle of November when DConf 2018 was announced here on the DBlog in a Q & A session with Andrei Alexandrescu. Since then, the DConf train has slowly been building up steam as things have been happening behind the scenes. Now it’s full steam ahead! https://dlang.org/blog/2018/01/31/dconf-2018-register-now Reddit: https://www.reddit.com/r/programming/comments/7udoi2/registration_for_dconf_2018_is_now_open/ Broken link: the link to the "DConf 2018 venue page" needs an extra 'l' at the end, i.e. venue.htm -> venue.html
Re: D's Newfangled Name Mangling
On 12/20/17 6:57 AM, Mike Parker wrote: Many thanks to Rainer for his insightful new article for the D Blog outlining the new name mangling algorithm. He talks about the old implementation and its limitations before going into the details of the new one. It's a topic I had never considered digging into before, even when the big Voldemort issue first popped up, but now I find it interesting. The blog https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/ Reddit https://www.reddit.com/r/programming/comments/7l1h36/ds_newfangled_name_mangling/ I really enjoyed this! Typo: "This is were I stepped in..." -> "..where.."
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.
Re: d_to_html.d
On 8/5/17 12:07 PM, WebFreak001 wrote: Hi, I made a D to HTML generator which is basically diet, but fully using the D compiler as generator and not some complicated parser, etc. [snip] That is amazing! I can't decide whether it's the best thing I've ever seen or a horrible hack, but it's a great showcase for what you can do with D.
Re: Life in the Fast Lane (@nogc blog post)
On 6/16/17 6:51 AM, Mike Parker wrote: I've been meaning to get this done for weeks but have had a severe case of writer's block. The fact that I had no other posts ready to go this week and no time to write anything at all motivated me to make time for it and get it done anyway. My wife didn't complain when I told her I had to abandon our regular bedtime Netflix time block (though she did extract a concession that I have no vote in the next series we watch). Thanks to Vladimir, Guillaume, and Steve, for their great feedback on such short notice. Their assistance kept the blog from going quiet this week. The blog: https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/ Reddit: https://www.reddit.com/r/programming/comments/6hmlfq/life_in_the_fast_lane_using_d_without_the_gc/ Great article! And thanks for sacrificing that Netflix time :)
Re: D compiler daily downloads at an all-time high
On 11/16/15 8:57 AM, Andrea Fontana wrote: So November is the dmd month and nobody knows. It would make more sense for it to have been D-cember.
Re: Please vote for the DConf logo
On 11/4/15 2:30 AM, Andrei Alexandrescu wrote: Reply to this with 1.1, 1.2, 2, or 3: 3
Re: LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!
On 9/17/15 8:15 AM, Jack Stouffer wrote: Building dungeon ~master ... Forgive the unhelpful reply, but this line made me happy :)
Re: SDLang-D v0.9.2
On 8/1/15 1:20 PM, Nick Sabalausky wrote: On Saturday, 1 August 2015 at 20:14:52 UTC, Nick Sabalausky wrote: On Saturday, 1 August 2015 at 17:57:30 UTC, John Colvin wrote: Haven't looked at this at all really, just a quick question: Are there straightforward library calls or command line utilities for converting between the shared subset of json and SDL? No, but there definitely should be. I'll post a ticket so I don't forget. https://github.com/Abscissa/SDLang-D/issues/30 Without having looked at the library, perhaps this util would make some good sample code.
Re: More Dconf 2015 videos
On 6/26/15 12:03 PM, Andy Smith wrote: I don't want to sound negative but the editing of Chuck's talk could be a lot better IMHO. Round about 30:00 he describes a code example which isn't shown in the video!. He's making multiple references to lines/code etc. that were visible to the attendees at the conference but aren't visible on the video. Having seen it in person, Chuck's talk was a *great* advocacy of D. But seeing it second time round on youtube I'm not feeling it the same way :-( I appreciate the work that UVU have put in to making the talks available so I *really* don't mean to sound unappreciative or disrespectful, but I think in this case it might make sense to go back and revisit this particular talk. Specifically when Chuck is talking about a specific code sample / line of code, it needs to be put into the video. Otherwise context is completely lost and viewers will be left confused + bewildered. Regards, Andy. Agreed; this was the one talk where I had to hunt down the slides on dconf.org, and then figure out where in the slides the code examples lived. Since the code examples are tiny pictures with links from the slides, this took me some figuring out.
Re: DCD 0.3.0, libdparse 0.1.0
On 9/5/14, 10:49 AM, Bruno Medeiros wrote: On 04/09/2014 22:48, David Gileadi wrote: On 9/4/14, 2:29 PM, Bruno Medeiros wrote: On 04/09/2014 09:06, Brian Schott wrote: If you've heard of Jedi or Gocode, I know gocode, but what's Jedi, out of curiosity? I couldn't google it because, well, Star Wars obviously.. The google is weak with you, young Padawan. Assuming from the context that it's some kind of autocompletion library like DCD you can search for https://www.google.com/search?q=jedi+autocomplete Lol, true that. I tried Jedi tool and Jedi code, but didn't occur to use autocomplete... (and the ones I tried still have a full Star Wars connotation) It does seem a bit iffy to be using that name for their tool from a legal standpoint, not to mention the search issue. Perhaps they're using some kind of mind trick on the trademark owners :)
Re: DCD 0.3.0, libdparse 0.1.0
On 9/4/14, 2:29 PM, Bruno Medeiros wrote: On 04/09/2014 09:06, Brian Schott wrote: If you've heard of Jedi or Gocode, I know gocode, but what's Jedi, out of curiosity? I couldn't google it because, well, Star Wars obviously.. The google is weak with you, young Padawan. Assuming from the context that it's some kind of autocompletion library like DCD you can search for https://www.google.com/search?q=jedi+autocomplete
Re: DConf 2014 Lightning Talks
On 8/7/14, 4:18 AM, Bruno Medeiros wrote: This is an interesting behavior I've come across, even before watching this talk: Recently I tried IntelliJ IDEA, and it also goes away with any explicit UI notion of saving a file. It just saves files automatically, as you type. This is interesting, and might well be a marked improvement in UI behavior... This is a UI direction that Mac OSX is going in, presumably as part of their push to bring iOS behavior to the desktop. Apps that use it save as they go, and they have a standard UI to browse through previous versions of your document if you want to go back to (or crib from) something earlier.
Re: DConf 2014 Opening Keynote: State of the struct address - Andrei Alexandrescu
On 5/30/14, 8:16 AM, florin wrote: Hi, In the opening of your keynote you mentioned the need of redesigning dlang.org. I'm more of a webdesigner than programmer so maybe I can lend a hand here. Is there a place where this is being discussed? Here's the thread where this was recently discussed (with a proposed design): http://forum.dlang.org/thread/mmoxalewsvwcgeaas...@forum.dlang.org Unfortunately the original poster has been quiet lately. I think you could perhaps continue evolving the design that he posted or else post a proposal of your own. I'm interested in helping out with whatever changes we make.
Re: Livestreaming DConf?
On 5/9/14, 12:48 PM, Andrei Alexandrescu wrote: Hi folks, We at Facebook are very excited about the upcoming DConf 2014. In fact, so excited we're considering livestreaming the event for the benefit of the many of us who can't make it to Menlo Park, CA. Livestreaming entails additional costs so we're trying to assess the size of the online audience. Please follow up here and on twitter: https://twitter.com/D_Programming/status/464854296001933312 Thanks, Andrei I'm interested but probably wouldn't be able to catch it all live due to work schedule. I'll definitely watch it all later at my own pace whether livestreamed or not. What I would hate is for livestreaming to be the only opportunity to watch it online.
