Re: Adding Markdown to Ddoc
On Tuesday, 12 December 2017 at 02:30:39 UTC, Walter Bright wrote: On 12/11/2017 2:30 PM, Jakob Bornecrantz wrote: It is not written in D, but the language is close enough in concepts that it can be mechanically ported into D, and is licensed under BOOST. Feel free to do what ever to it[1]. Thank you for Boost licensing it! Happy if it can help you in anyway. We have imported some code from Druntime/Phobos as well, so licensing it all under BOOST made sense. We first used the markdown parser from vibe.d, when we threw the CommonMark testsuit, 10 tests segfaulted and 1 infinite-spun in a loop somewhere in the code. We then rewrote from scratch using the recommended practices from the CommonMark spec and the XML output from cmark as a guide. The code is used in our documentation system. Both doc-comments and outside documentation files are written in CommonMark. The doc-comments uses Doxygen tags which is then run through CommonMark, most of the time it does nothing to the comments, but if you want to write long comments it makes it much more natural and enjoyable. [1] https://github.com/VoltLang/Watt/tree/master/markdown/src/watt/markdown It's apparently written in Volt: https://github.com/VoltLang/Watt It's a language a small group of people (me included) have been working on for a while, I avoid naming it here because it's a system level language like D. I don't want to advertise it in any form here to keep the discussion on D. But in this case the intent was code sharing. :D Cheers, Jakob.
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 20:45:38 UTC, Walter Bright wrote: On 12/11/2017 6:22 AM, Jakob Bornecrantz wrote: There are loads of implementations of CommonMark https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations They appear to be libraries that offer an implementation. Does the Markdown used in github, reddit, wikipedia, doxygen, etc., use any of those libraries? Github in the past used something called Github Flavored Markdown, which was Markdown + whatever quirks where in the ruby implementation of Markdown + Tables. Not Markdown. The same with all of the others, they all had different quirks because the markdown "spec" was bad. Let me use a different technology as a analogy. Walter: We should use HTML for DDOC! Others: Cool, but can you use CommonTML (HTML5), it has this cool spec and actual tests that make sure it looks the same, and that the code you have written is robust. HTML isn't really a standard as such, you are not sure what you get and there is no agreed upon testsuit, so you aren't even sure you get the same results with different versions of your own code. Walter: Is this used elsewhere? I really want HTML. Others: Here is the spec and a bunch of implementations. Walter: But HTML is more common, its used in Netscape Navigator and IE6. Others: *collective headdesk* What I'm trying to get at is, use the testsuit and spec, it will save you lot of other problems down the road. And you will be making the world of Markdown a better place because there will be one less implementation that does things slightly differently. the one I have written is not listed. That covers 1 and 2. I didn't know you wrote one. There are 3 Markdown packages on Dub: https://code.dlang.org/search?q=markdown and I don't see your name on them. I strongly recommend you register yours with Dub (if it is in D) and on the commonmark site! It is not written in D, but the language is close enough in concepts that it can be mechanically ported into D, and is licensed under BOOST. Feel free to do what ever to it[1]. We first used the markdown parser from vibe.d, when we threw the CommonMark testsuit, 10 tests segfaulted and 1 infinite-spun in a loop somewhere in the code. We then rewrote from scratch using the recommended practices from the CommonMark spec and the XML output from cmark as a guide. The code is used in our documentation system. Both doc-comments and outside documentation files are written in CommonMark. The doc-comments uses Doxygen tags which is then run through CommonMark, most of the time it does nothing to the comments, but if you want to write long comments it makes it much more natural and enjoyable. [1] https://github.com/VoltLang/Watt/tree/master/markdown/src/watt/markdown
Re: Adding Markdown to Ddoc
On Monday, 11 December 2017 at 00:54:00 UTC, Walter Bright wrote: On 12/10/2017 6:22 AM, meppl wrote: I think these are wrong criterias to estimate the value of commonmark. Commonmark doesn't need to list anyone and doesn't need to be listed by anyone to be a standard. commonmark is a standard proven by following "facts": 1) whenever a language feature is used by all popular markdown languages, it is standard 2) there are markdown features who are used by all popular markdown languages 3) everyone can reveal this matter of fact - e.g. by writing it down as a specification 4) any language feature published by the commonmark-spec is used by all popular markdown languages ergo: commonmark == standard markdown well, at least, if the commonmark people did their homework right I have a more pragmatic definition of a standard: 1. Products that implement it say they adhere to it and defer to it as the authority on correct behavior. 2. There's more than one such product. 3. There's more products adhering to that standard than some other competing standard. So far as I know, commonmarkdown satisfies zero of those. Don't get me wrong, I think commonmarkdown is a worthy effort, and is definitely in the running to be a standard. Certainly a lot more effort seems to have been put into it vs other markdowns. It is entirely reasonable to refer to it to answer questions about whether some detail should yin or yang. But implementing commonmarkdown in Ddoc is not what we're going to do, at least for the near term. There are loads of implementations of CommonMark https://github.com/commonmark/CommonMark/wiki/List-of-CommonMark-Implementations the one I have written is not listed. That covers 1 and 2. Also Markdown is not a standard, it started out as a pearl script and the a short documentation on how to write text for it. It has several ambiguities, leading to a lot of implementations do things differently. So they don't agree on the authority of Markdown. Which makes Markdown a mess because you don't know what behaviour you will get from the different implementation. So that covers 3. And to add more, CommonMark on the other hand has a full spec written and several test that covers the difficult to get right parts of Markdown/CommonMark. I'm sure I don't need to tell you the virtues of a good test suit. Cheers, Jakob.
Re: Webassembly?
On Thursday, 6 July 2017 at 22:58:36 UTC, Ola Fosheim Grostad wrote: On Thursday, 6 July 2017 at 18:26:18 UTC, Joakim wrote: so you can seamlessly pass objects to javascript. I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same. You would have to emulate the stack... WebAssembly has linear memory that you can scan just like normal memory. C programs use it for those values on the stack that it needs a pointer to. For other values they are put on the safe stack, you can only read the value not the memory backing it. So there is a problem of pointers going on the safe stack so you need to make sure to not optimise those pointers to the safe stack. But in short, the D GC will work just fine, just need to be a bit carefull with pointers on the stack. Cheers, Jakob.
Re: MS-COFF/PDB support in LLVM/LDC, where are we at?
On Thursday, 15 June 2017 at 01:34:01 UTC, Manu wrote: Hey people, I haven't checked in for a while, I'm yet again tempted to use D for a small work thing, but I'll need LDC for it, and debuginfo needs to work or it's a non-starter. Does anyone know where that stuff stands? What are the limits? Last I checked, some MS guys were personally introducing full debuginfo to LLVM, but I'm not sure if they progressed, or if that work is available in LDC? Cheers. - Manu Google tells me that at least LLVM should support it[1]. Dunno about the rest of LDC. Cheers, Jakob. [1] http://clang.llvm.org/docs/MSVCCompatibility.html
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
On Tuesday, 19 July 2016 at 16:13:21 UTC, Atila Neves wrote: On Tuesday, 19 July 2016 at 16:01:01 UTC, Lodovico Giaretta wrote: On Tuesday, 19 July 2016 at 15:48:26 UTC, Atila Neves wrote: Small string optimization should _help_ std::string, no? Atila Small string optimization will make the struct bigger, thus making swapping slower. If the struct is no bigger than 2 pointers, swapping it is ultra fast. Interesting. Read up on it and tried changing the strings to be ~50 chars long. C++/std::string gets better, but C++/const char* still beats D by a small margin: C: 1.852s C++/std::string: 1.489s C++/const char*: 1.034s D: 1.188s Could be the cost of swapping the "fat" in "fat pointer", in which case: worth it. You are swapping different amount of data. For C++/const char* vs D, you are swapping 75% more data. For D vs C++/std::string, you are swsapping 129% more data. I would expect you getting the same numbers if you did "const(char)*" version in D? And if you used a inline sort[1] in the C version it would probably be just as fast as the C++/const char* version. Also it was a bit hard to find out what N you where using. Cheers, Jakob. [1] http://www.corpit.ru/mjt/qsort.html
Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote: On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote: Posted on Atila's blog yesterday: https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/ So, about D vs C++ there... last night for reasons I forget I tried replacing std::string with const char* in the C++ version, and then it got faster than D. I don't know why. At first I thought std::string was being copied instead of being moved, but some static_asserts made me doubt that. Either way, there's no good reason I can think of for C++ to magically speed up for const char*. Hmm :( Atila What is the sizeof(Foo) for all of the cases? What does "charPtr < charPtr" do in C++ compared to std::string? Cheers, Jakob.
Re: GPGPU work and Identifiers
On Sunday, 19 June 2016 at 14:04:15 UTC, Nicholas Wilson wrote: On Sunday, 19 June 2016 at 12:38:00 UTC, Jakob Bornecrantz wrote: On Sunday, 19 June 2016 at 11:12:50 UTC, Nicholas Wilson wrote: This thread is partly to announce that i will be adding to LDC the ability to generate code for GPUs through OpenCL, CUDA (and if i have time) Metal in my fork at https://github.com/thewilsonator/ldc and partly to request the reservation of the relevant Version identifiers. (Do I do this by a pull request?) What is your current status? Just starting. But I know what i need to do ( in terms of metadata) Ah okay. Is that SPIR-V or SPIR? SPRI-V I tought that LLVM did not have a SPIR-V backend mainlined. Or are you using a out of tree one from Khronos? Yes That will be annoying, the LDC that works with SPIR-V wont be able to produce MSVC compatible exes. Lets hope they mainline it soon. Thanks for the reply. Cheers, Jakob.
Re: GPGPU work and Identifiers
On Sunday, 19 June 2016 at 11:12:50 UTC, Nicholas Wilson wrote: This thread is partly to announce that i will be adding to LDC the ability to generate code for GPUs through OpenCL, CUDA (and if i have time) Metal in my fork at https://github.com/thewilsonator/ldc and partly to request the reservation of the relevant Version identifiers. (Do I do this by a pull request?) What is your current status? Is that SPIR-V or SPIR? I tought that LLVM did not have a SPIR-V backend mainlined. Or are you using a out of tree one from Khronos? Do you have any examples? Cheers, Jakob.
Re: Phobos Action Items
On Saturday, 18 June 2016 at 20:04:50 UTC, Walter Bright wrote: 8. create a greenthreads module that works like Goroutines Please don't use the term gorourines when describing a bunch of library functions. There is more to them then just functions. You will need compiler and GC support for the special stack that they have. Cheers, Jakob.
Re: Pitching D to a gang of Gophers
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote: What features you'd highlight to enterprise-ish user? Have go solved stacktraces in gorutines, last I checked this was a big pain point for go developers, otherwise its a good issue to bring up. Cheers, Jakob.
Re: [OT] LLVM Community Code of Conduct
On Wednesday, 28 October 2015 at 17:36:03 UTC, Walter Bright wrote: On 10/28/2015 2:12 AM, Jakob Bornecrantz wrote: You are not in good company tho. Even the page you link to says nobody else could or should say stuff like that. And attitudes like that will only disurage people from trying to improve this community. http://sarah.thesharps.us/2015/10/05/closing-a-door/ https://mjg59.dreamwidth.org/38136.html These are different times. I did not mean that absence of a Code of Conduct is license to abuse others. Just that a CoC is itself insulting, paternalistic, and not a solution. Fair enough. Its a shame you see it as insulting. I pose you this question: if I as a new person coming to this community and felt that I was being treated unfairly, badly or any other form where should I turn to? Is this documented somewhere? Building onto that how should I expect to be treated, you mentioned decent, how do you define decent? Cheers, Jakob.
Re: [OT] LLVM Community Code of Conduct
On Wednesday, 28 October 2015 at 17:13:27 UTC, deadalnix wrote: http://sarah.thesharps.us/2015/10/05/closing-a-door/ https://mjg59.dreamwidth.org/38136.html These are different times. Yup, professional victim use to not be a viable career path. What do you mean? Cheers, Jakob.
Re: [OT] LLVM Community Code of Conduct
On Wednesday, 28 October 2015 at 08:36:07 UTC, Walter Bright wrote: On 10/13/2015 12:13 PM, Walter Bright wrote: On 10/13/2015 6:36 AM, Daniel Kozak wrote: lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html Maybe we could have something similar in D community No. People who need to be told what decent behavior is won't pay attention to such a document. Apparently I'm in good company: "trying to come up with some ‘code of conduct’ that says that people should be ‘respectful’ and ‘polite’ is just so much crap and bullshit” -- Linus Torvalds, https://gumroad.com/l/prQdM# You are not in good company tho. Even the page you link to says nobody else could or should say stuff like that. And attitudes like that will only disurage people from trying to improve this community. http://sarah.thesharps.us/2015/10/05/closing-a-door/ https://mjg59.dreamwidth.org/38136.html These are different times. Cheers, Jakob.
