Re: D for BigData: the first BetterC library by Tamediadigital
On Monday, 2 May 2022 at 05:22:07 UTC, test123 wrote: https://forum.dlang.org/post/hngfeheyklalzoxky...@forum.dlang.org On Saturday, 25 February 2017 at 14:32:00 UTC, Ilya Yaroshenko wrote: HyperLogLog++ is advanced cardinality estimation algorithm with normal and compressed sparse representations. It can be used to estimate approximate number of unique elements in an unordered set. hll-d [1, 2] is written in D. It can be used as betterC library without linking with DRuntime. hll-d has C header and C example. Its implementation is based on Mir Algorithm [3] 1. mir.ndslice.topology.bitpack is used for arrays composed of packed 6bit integers 2. mir.ndslice.sorting.sort is used for betterC sorting. [1] Git: https://github.com/tamediadigital/hll-d [2] Dub: http://code.dlang.org/packages/hll-d [3] Mir Algorithm: https://github.com/libmir/mir-algorithm Best regards, Ilya Thanks for the great work. I check the c api, can not figure out how to get the count number for one element. For example if I use it as IP counter, is there a way to know how much count for one IP has been add into set ? No, that's not what this is for. Hyperloglog is useful if you have a big dataset that may contain duplicates and you want to know how many unique items you have (with a reasonnable probability). For example, as a website, this can be used to estimate how many visitors you have without having to store every single IP address to check for duplicates at new connections. The tradeoff is that it's probabilistic: you don't need to store every address so you need much less space and time to get a count of unique ips, but you have to accept a margin of error on that result and you can't know what the IPs were in the first place, just how many of them there are.
What Mike thinks
On Thursday, 17 September 2020 at 13:45:16 UTC, Mike Parker wrote: What Mike thinks appears nowhere in my post :-) That's a bit sad. I understand that in your position it may be hard to express a personnal opinion but I think anyone should get the opportunity to do so. Would you like, in no official capacity whatsoever, to provide your personnal take on the matter? I think you should get to express your feelings as well :) But of course I would understand if you don't want to get involved in any particular issue.
Re: A security review of the D library Crypto
On Saturday, 4 July 2020 at 14:37:41 UTC, H. S. Teoh wrote: I'm not the author, but I'm curious about the D implementation of Botan (https://code.dlang.org/packages/botan) -- how is its security level? I glanced at it before and it seemed OK, but it'd be really nice to have a 3rd party opinion, esp. from someone who's skilled with cryptanalysis. T I can't say much at the moment. Botan is another beast altogether and lots of work is going to be required to get any certitude. What I can say is that it's a nice library, ported from a library that has been audited in the past and is still actively maintained. A cursory shows none of the issues found in Crypto. Everything seems really good. The main issue with Botan from a design standpont may be its completeness. It's great if you are building off an established project or protocol and need specific algorithms. If you're starting a new project from scratch though more options mean more ways to potentially chose a bad one. I mentionned libsodium in a previous answer; this is the kind of opiniated library that is well suited to that type of new projects. But really, it's hard to say anything bad when the project's wiki starts with a list of books and resources to learn cryptography prior to using the library [1]. I don't know the author but at least it seems like he knows what he's messing with. So, to conclude, based on that preliminary look alone I would feel confident about recommending Botan since I don't expect any major issue. But I'll still need to find the time to properly review it someday, be it only for my own peace of mind. [1]: https://github.com/etcimon/botan/wiki
Re: A security review of the D library Crypto
On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote: On Wednesday, 1 July 2020 at 07:19:11 UTC, Cym13 wrote: Here's what you should know if you are a user: RSA, as implemented in the library, is still very much broken. I do not recommend using it. The confidentiality and integrity of all messages exchanged using this library must be questionned: if you exchanged sensitive information such as passwords using it I recommend to change them since their security is not guaranteed. [snip] Thanks for the article. IMO it was as clear for non-professionals as crypto can be: Even I (non-crypographer) understood what's the problem with padding with only one byte. Thank you for that feedback. It also illustrates what's the prolem with cryptography: it's like coding without ability to test. Who could even dream to get that right the first or even the second time? I think there a shortcoming in the "don't roll your own crypto" - advice: One could think it only applies to the algorithms, not the implementation. That's what I did when I first heard it. There's one more element missing here: the protocol. Cryptography isn't about encrypting stuff, it's about protecting secrets from start to finish and that includes the protocol used. To take an example, many people can think "Hey, I need encryption between my two servers, I'll use AES" and stop there. But use AES how? What mode (CBC,GCM,...)? Let's say CBC is used, what about message authentication? Can I just modify your stream? How is the key exchanged? How is the key generated? Etc. People tend to focus on encryption, be it algorithm or implementation, but once you've got bricks it's still a pain to put them together in a solid way. Things like TLS or SSH actually combine at least 3 completely different sets of bricks to establish the communication, authenticate it, secure it once established etc. So, in a way, "don't roll your own crypto" means "use TLS as much as possible" :) If one needs to use cryptography, would redundancy help? I mean, encode and decode the message with say three different algorithms from different libraries, so that the attacker would need to find a weakness in all of them? That's a good question. The general answer is: no. The more detail answer is: in some cases it can help (I know of one client for example that doesn't trust national standards and has layered US technology with Russian technology to make sure that at least one layer stands). However in the general case we can prove that the security of the combination is less than or equal to the security of the better of the elements of that combination. In some cases badly choosen algorithm actually counteract each other leading to easier attacks. My general advice is to stay true to well audited implementations of good standards. I like opiniated libraries in that context so I'd say "whatever libsodium implements".
Re: A security review of the D library Crypto
On Wednesday, 1 July 2020 at 07:49:27 UTC, Arafel wrote: As somebody who also was somewhat involved in infosec and cryptography in a previous life, I found your article really interesting. So, first of all, thanks for taking the time to do the review and for publishing the results! I see that you mostly focus on the algorithms, but did you also check for side-channel attacks (for instance, timing attacks), or given the flaws already found it would make little sense to go deeper? Fixing the issues from the article would require a huge amount of code changes, so I saw little point in timing the library as is. It must do the right thing before doing it the right way. I find that following a well-known algorithm is just the easy part when implementing crypto... the hard one is ironing out those pesky "implementation details". That's one of the reasons why I would try to use one of the "big" libraries for cryptography instead of rolling out my own, even if it meant adding an external C/C++ dependency to my project. I can definitely vouch for that.
A security review of the D library Crypto
As some of you may know one of my hobbies is to review open source software for security issues. About a year ago I reviewed the RSA implementation of Crypto[1]: a native D library which, according to dub statistics, is fairly popular. Issues were found and after discussion with the author I decided to wait for them to be fixed. A year later I would like to present the results of an updated review of the library: https://breakpoint.purrfect.fr/article/review_crypto_d.html Here's what you should know if you are a user: RSA, as implemented in the library, is still very much broken. I do not recommend using it. The confidentiality and integrity of all messages exchanged using this library must be questionned: if you exchanged sensitive information such as passwords using it I recommend to change them since their security is not guaranteed. “Is this really the place to have this discussion? Shouldn't this be between the author and you?“ The author was contacted a year ago and although our discussion was kind and productive I have not heard from him since. Most of the issues present today were already present in my first assessment. Some modifications were made, but most recommendations were ignored. After a year without action I feel that the users should know exactly what they are exposed to since they are the ones affected by these security issues. This follows standard vulnerability disclosure processes. For all details and analysis I direct you to the blog post. It is a rather thorough and technical read so I would recommend grabbing a cup of tea first. If you find any mistake or unclear parts I'll be glad to correct it so feel free to point it out. Furthermore if you would like someone to have a look at your project to identify issues I am always glad to help free and open source projects that can't afford security review through traditional means so feel free to reach out. [1] https://code.dlang.org/packages/crypto
Re: Novelate - Visual Novel Engine
On Thursday, 23 January 2020 at 15:19:34 UTC, bauss wrote: Novelate is a visual novel engine written in D. It officially binds to SFML but the engine itself has no direct dependencies on SFML as there's plans for supporting libraries such as SDL etc. in the future too. It's still a work-in-progress but the basics are done as of now and it has reached a point where publishing it as open-source is possible. Preview: https://i.imgur.com/YyoIWkp.png For more information see: Github: https://github.com/Novelate/NovelateEngine Dub: https://code.dlang.org/packages/novelate A website with documentation etc. is coming soon as well! Thank you! Love the initiative, I'll be sure to keep an eye on this!
Re: A tutorial teaching the basics about multimedia with the arsd library
On Sunday, 30 June 2019 at 23:46:27 UTC, Murilo wrote: Hi everyone, I am writing a tutorial teaching the basics about multimedia programming using the arsd library. This is a library all D programmers should have since it is very useful and easy. In this tutorial I will teach in a fun and easy way how to use it for GUIs, image displays, games, etc... Here is the GitHub link: https://github.com/MuriloMir/arsd_multimedia_tutorial And please join the official facebook Dlang group: https://www.facebook.com/groups/ProgrammingInD/ I really dislike that you use screenshots of code, it makes copy-pasting impossible. There are ways to produce pdfs with colored, copyable source code (like using RST for redaction then rst2pdf for production, but I'm not sure it'll be the easiest for you).
Re: my first kernel in betterC D
On Wednesday, 19 June 2019 at 23:31:40 UTC, Laeeth Isharc wrote: On Wednesday, 19 June 2019 at 13:45:45 UTC, matheus wrote: ... One aspect of that is just showing something is possible. Adam Ruppe's talk at dconf a while back has had a lasting influence on how we approach things, mostly for giving me permission to do what I'm naturally inclined to do anyway. If you're not sure then bet a little time to try - the worst thing that can happen in user code is a segfault and so what. What talk is that exactly?
Re: DConf 2019 Videos
On Wednesday, 5 June 2019 at 02:37:57 UTC, Mike Parker wrote: On Tuesday, 4 June 2019 at 09:58:26 UTC, Mike Parker wrote: I can't predict how long it will take, but when I get the first one uploaded I'll post a notification in this thread so that everyone can follow as they go up. I'll go in the order of the schedule from Day 1 to Day 3. The DConf 2019 playlist is available at: https://www.youtube.com/playlist?list=PLIldXzSkPUXWORGtUrnTo2ylziTHR8_Sq Walter's keynote is up now. Others will be available soon. Again, I can't predict how long until they're all up, but they're coming. I was pretty worried about the videos because of past issues but I must say that those videos are great, the sound is good, it's readable and enjoyable to watch, and they're on time. Thanks everyone for a job well done on that front.
Re: [DCONF] Is the even streamed?
On Wednesday, 8 May 2019 at 07:22:05 UTC, Cym13 wrote: Hi, I haven't found any information related to streaming of the event. Is there any way for non-participant to see these conferences? Also, will they be recorded? (Oops, this was supposed to be in General)
[DCONF] Is the even streamed?
Hi, I haven't found any information related to streaming of the event. Is there any way for non-participant to see these conferences? Also, will they be recorded?
Re: Darser: A LL(1) to Recursive Decent Parser/AST/Visitor Generator
On Wednesday, 20 March 2019 at 17:20:48 UTC, Robert Schadek wrote: To get graphqld up and running I needed a parser/ast/visitor. Being lazy, I created parser/ast/visitor generated for that. [...] This looks nice! I'm familiar with pegged which uses PEG grammars, could you maybe comment on the differences and possible benefits of Darser in comparison?
Re: Release D 2.085.0
On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote: Glad to announce D 2.085.0, ♥ to the 49 contributors. This release comes with context-aware assertion messages, lower GC memory usage, a precise GC, support to link custom GCs, lots of Objective-C improvements¹, and toolchainRequirements for dub. This release also ended official support for OSX-32. http://dlang.org/download.html http://dlang.org/changelog/2.085.0.html ¹: There is a pending Objective-C fix (https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 but will be released with 2.085.1 soon (~1.5 weeks). -Martin In the -preview/-revert it is said: As of now, DMD offers these reverts: -preview=dip25: Reverts DIP25 changes -revert=import: Revert to single phase name lookup Shouldn't that be "-revert=dip25" instead of -preview there?
Re: hunt-markdown 1.0.0 released,
On Tuesday, 19 February 2019 at 10:36:38 UTC, zoujiaqing wrote:
hunt-markdown is powerfull markdown spec parsing and randering
library for Dlang. It's fast and clean. Api design like java's
commonmark library.
example code:
```import hunt.markdown.node.Node;
import hunt.markdown.parser.Parser;
import hunt.markdown.renderer.html.HtmlRenderer;
Parser parser = Parser.builder().build();
Node document = parser.parse("This is *New*");
HtmlRenderer renderer = HtmlRenderer.builder().build();
renderer.render(document); // "This is New\n"
```
More markdown spec like this:
https://spec.commonmark.org/0.28/
Github reposirory:
https://github.com/huntlabs/hunt-markdown
A cool addition would be a sanatizer to allow processing markdown
provided by users in a secure way. Right now trying to build
something like a forum supporting markdown would only end in lots
of XSS everywhere.
The end developer could probably create a sanatizer himself but:
* security works best when the wheel isn't invented over and over
again, such piece of software is hard to get right[1], better
have a centralized effort
* writting a sanitizer requires building a MD parser so it's
worth baking it into the library (but with a way to disable it
for trusted inputs).
Otherwise, it would be good to mention that this is not fit to
manage user inputs and should be kept server-side.
[1]:
http://danlec.com/blog/hacking-stackoverflow-com-s-html-sanitizer
Re: On D in competitive programming
On Sunday, 29 July 2018 at 07:51:00 UTC, Jim Balter wrote: On Saturday, 28 July 2018 at 21:33:04 UTC, Ivan Kazmenko wrote: [snip] 2. When you briefly explain templates I think it's important to mention that empty parentheses may be omitted to allow the reader to make the link between function!(arg1)(arg2) and map!something. Explaining UFCS isn't necessary there though I think since it's obvious that there is some kind of chaining at play (not that you did, just thinking out loud). Yeah, good point, mentioned it now. Actually, map!something does not drop empty parentheses, so mentioning that does not help. Parentheses containing 0 or 1 arguments can be omitted ... and you omit them for 1 argument in 3 places, and no instances of omitted empty parentheses. And I think it would be less confusing to an unfamiliar reader to mention UFCS, because the chained calls don't fit the function !(args1) (args2) syntax that you mention. [snip] While it's certainly not exact I think it's fine, there's no need to rewrite the language specification. Even for the parentheses, once you know they may be dropped in unambiguous cases you are bound to assume that the author didn't start talking of the ! sign for no reason and that you ought to consider that parentheses may be dropped even not knowing all the reasons. The same goes for UFCS, it's made very clear by the article that the functions are chained. Whether they are actually functions, or function templates or methods or something else entirely isn't important. I think the reader can be expected to understand how it works without understanding why. They even know what the program does already so the chaining part isn't hard. Maybe I was wrong that it needed any addition after all. Or maybe the explaination of templates should be more streamlined toward what is in the code like “map here is a template, the ! sign is the equivalent of <> in C++" and no more.
Re: On D in competitive programming
On Saturday, 28 July 2018 at 19:51:08 UTC, Ivan Kazmenko wrote: Hey, I wrote a post with my general reflections on using D in competitive programming. Mostly compared to C++, since that's what more than 90% of people use for it. The post is tailored to cover only the competitive programming specifics. http://codeforces.com/blog/entry/60890 (en+ru, the language switch is at the top) Ivan Kazmenko. Thanks, great read :) I have some minor notes though: 1. Your real name isn't written in the article so the link "with some successes" won't tell much to someone that doesn't already know you 2. When you briefly explain templates I think it's important to mention that empty parentheses may be omitted to allow the reader to make the link between function!(arg1)(arg2) and map!something. Explaining UFCS isn't necessary there though I think since it's obvious that there is some kind of chaining at play (not that you did, just thinking out loud). Also I have a question: I find very nice that some platforms propose D even though not all do, but are they generally keeping it up to date with DMD or stuck at something ancient?
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote: That would work, it's just a really horrible hack and I hate it. Bastiaan's solution to simply change the default value slipped my mind but is really cleaner and in the same line of thought. We're constructing a fictitious domain value that passes our invariants while having zero correspondence to the real world, *just to pass our invariants*. It's an obvious sign of a language issue. I'm not sure I understand, that's what T.init is: a fictitious domain value that just happens to be the default value. It doesn't have to have any meaning and shouldn't be used that way. It's just a value until it has a value. If it happens to be conveniently a useful value, all right, but that's not its first goal IIUC. To present things the other way: you are defining constraints on a type while also defining the default value of that type as not meeting these contraints. No matter how you look at it the default value of a type should be a valid value. How is that not an issue with your own code? Just change the default so that it is within the constraints. Furthermore, while changing the default field value directly is less of a hack the solution to redefine init() entirely actually allows you to do things like making sure the struct is registered in a table somewhere. So I think you do have the option to meet your invariants.
Re: Blogpost about the T.init problem
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Related links:
https://github.com/dlang/phobos/pull/6594 problem with T.init
and toString
https://github.com/dlang/phobos/pull/6619 Nullable can't work
with types where T.init violates invariants
https://github.com/dlang/dmd/pull/8462 A somewhat sketchy PR to
disable invariant on struct ~this
First of all I must point that I would very much like to have
seen a code actually producing an error in that article. Contrary
to what is hinted just taking the struct and putting using it
with Nullable or format() caused no error for me and worked as
expected. Taking .init explicitely was the only thing that
actually caused an error. I'm not saying you didn't experience
these issues, but if you want to demonstrate a problem then
please demonstrate it.
That said, I may be missing something obvious but what prevents
you from overloading the init field?
struct MyDomainData {
string username;
@disable this(); // don't make a MyDomainData() by
accident!
this(string username)
in(!username.empty) // only non-empty usernames please!
do { this.username = username; }
// let's formalise the restriction.
invariant { assert(!username.empty); }
string toString() { ... }
static @property MyDomainData init() {
return MyDomainData("uninitialized");
}
...
}
auto test = MyDomainData.init; // There, no error
Of course that value means nothing but .init isn't meant to
actually mean something anyway, it's just a valid value and
that's what that init is proposing, so it shouldn't cause any
more bugs than empty .init in a normal case.
Re: Encouraging preliminary results implementing memcpy in D
On Thursday, 14 June 2018 at 02:32:51 UTC, errExit wrote:
Tor is our last line of defence against an Orson Wells future,
where everyones actions are scrutinized by big brother, so that
big brother can use that knowledge to put fear into, control
and manipulate, those that don't conform.
assert("bad tor user" != "all tor users are bad");
(actually there are more bad non-tor users)
Unfortunately, it's becoming increasingly, the norm, to
discriminate against tor users (no doubt those doing that
discrimination are those that are happy to conform, of which
there will be many, sadly).
https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf
Don't mistake spammer management with discrimination. I share
your frustration that TOR isn't more usable than it is today with
CloudFlare etc, but coming with political reasons holds no water
if the reason why it was blacklisted wasn't political in the
first place. It's not false, it just won't work.
Hopefully once that particular user gets discouraged or we find a
way to actually avoid user impersonification, then things will be
able to come back to normal.
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 16:21:53 UTC, Steven Schveighoffer wrote: I won't add much, since I'm using a Mac, and those numbers have already been posted. Reproduction is an important part of the scientific process, please post away ;) Also: memcpyD commit f5fb0fda0dbacc960ced59d7171ff76a95cc2abf on Archlinux native x86_64 4.16.13-2 with Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz and 7681MB of RAM, with dmd and ldc, no flag and optimized. DMD: size memcpyC memcpyD 1 50392 30745 2 50189 33515 4 47493 33456 8 50282 33428 16 36385 36061 32 36212 32142 64 50141 31137 128 52947 52785 256 86422 76346 512 131191 128344 1024 227875 291414 2048 444865 449210 4096 826391 823613 8192 1542429 1545051 16384 3264964 3228990 32768 11644816 11902418 65536 23658237 24026304 size memcpyC memcpyD 1 43209 37462 1 42412 38043 1 42079 38002 2 56503 39923 2 50544 38033 4 47760 37239 4 48910 36976 8 51110 38065 8 53761 36297 4 48201 35548 8 54820 38036 16 39360 35409 DMD -O: core.exception.AssertError@memcpyd.d(9): Assertion failure ??:? _d_assertp [0xc4e79cc5] ??:? pure nothrow @nogc void memcpyd.verify!(real).verify(const(real), const(real)) [0xc4e77c2c] ??:? void memcpyd.test!(real).test() [0xc4e76d60] ??:? _Dmain [0xc4e63ecd] 1 42014 26518 2 46086 26486 4 45984 29272 8 48813 26484 16 34866 18126 32 32036 18107 64 46073 20892 128 45964 27993 256 82344 50250 512 133484 94766 1024 216402 270462 2048 436465 443122 4096 815875 801596 8192 1524872 1530453 16384 3721245 3584620 32768 11776185 11739396 65536 23702074 23589480 size memcpyC memcpyD 1 37755 15424 1 40486 15319 1 40505 15352 2 47097 15653 2 46160 15319 4 43180 18110 4 46041 15321 8 46014 15342 8 46066 15341 4 43277 18105 8 45962 15321 LDC: size memcpyC memcpyD 1 56378 48873 2 59461 49025 4 50481 45299 8 53786 49517 16 46103 39122 32 48100 46139 64 83864 67401 128 83849 90426 256 122471 138309 512 169668 228472 1024 260461 276878 2048 444937 472365 4096 860962 825468 8192 1578929 1567154 16384 3429235 3284611 32768 11941494 11868947 65536 24052536 24112980 size memcpyC memcpyD 1 47853 33403 1 47623 32924 1 48190 33100 2 59752 33146 2 59574 34371 4 53928 35042 4 54131 31991 8 57929 35864 8 57372 32174 4 54901 33253 8 62537 34535 16 52487 38358 LDC -O2: core.exception.AssertError@memcpyd.d(9): Assertion failure ??:? _d_assert [0x7fba47d79b35] ??:? void memcpyd.test!(real).test() [0x5638cb483d6e] ??:? _Dmain [0x5638cb47ea30] size memcpyC memcpyD 1 0 0 2 0 0 4 0 0 8 0 0 16 385 0 32 792 0 64 1542 0 128 2981 0 256 90108 0 512 126316 0 1024 217881 391419 2048 415182 620853 4096 1244805 1240074 8192 2428417 2414095 16384 4863280 4971193 32768 12968909 12966676 65536 26393408 26395410 size memcpyC memcpyD 1 0 0 1 0 0 1 0 0 2 0 0 2 0 0 4 0 0 4 0 0 8 0 0 8 0 0 4 0 0 8 0 0
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 03:57:37 UTC, Suliman wrote: Git was never my favorite VCS. So I hope that this step will open door for project like pijul.org github.com is only site, not religious. So if it will be closed people will move/create to its analogs. Git has nothing to do with github, it's just a technology they happen to use but they have no privilege on it. It won't change a thing on that side.
Re: unit-threaded v0.7.45 - now with more fluency
On Wednesday, 9 May 2018 at 04:40:37 UTC, Nick Sabalausky (Abscissa) wrote: On 05/08/2018 05:05 AM, Cym13 wrote: [...] No, it really doesn't mean the same thing at all. Not when you look away from the unimportant implementation details and towards the big picture: [...] With UFCS I find that in my code a dot means "function composition" more often than "is a member of". Maybe it's just that I like writting in a functional style, but UFCS chains are very much endorsed by the language, so I wouldn't call it a stretch.
Re: unit-threaded v0.7.45 - now with more fluency
On Tuesday, 8 May 2018 at 07:07:30 UTC, Nick Sabalausky (Abscissa) wrote: On 05/07/2018 11:57 PM, Johannes Loher wrote: On Monday, 7 May 2018 at 09:19:31 UTC, Dechcaudron wrote: I think I'm siding with Johannes here. Much as the overloads look nice, I don't really see the advantage over `shouldEqual`. Also, what's with `all.these.identifiers`? Any particular reason why you are more fond of them rather than of good ol' pascalCase? Fluent assertions have one major advantage over using pascalCase assertions: There is no ambiuguity about the order of arguments. When using e.g. assertEquals, how do you know wheter is is supposed to be assertEquals(actual, expected), or assertEquals(expected, actual)? The first one is the only one that makes sense wirh UFCS, but it is not clear directly from the API. On top of that, some popular Frameworks (I‘m looking at you, JUnit...) do it exactly the other way round. With fluent assertions, you don‘t have this Problem, it is much more clear that it should be actual.should.equal(expected) and not expected.should.equal(actual), because it fits naturally in the chain of ufcs calls. I don't think that's the issue. At least, it isn't for me. It's not a question of "assert equals" vs "should equal" (Though I am convinced by your argument on that matter). The question is: Why "should.equal" instead of "shouldEqual"? The dot only seems there to be cute. Not that I'm necessarily opposed to any of it (heck, I like cuteness in any sense of the word), it's just that: If the "~" thing is operator abuse, then I don't see how "should.equal", "should.not.be" etc, wouldn't fall into the same category. I wouldn't say it's an abuse, the dot means exactly the same thing as everywhere else in the language. I'm way less fan of overidding ~ since that doesn't have that meaning in any other context. Without having actually used it, I like the composability over pascalCasing here, it looks like it fits nicely in a functional environment with things like aliases and partials I think, defining your own primitives naturally... Nothing one can't do with regular functions and pascalCased assertions, but it sounds like it would be way more verbose. It also sounds like it's easier on the implementation side since you never have to define both a "shouldSomething" and "shouldNotSomething", and that means as a user I can expect less bugs and better maintainance of the library. That said, it'll have to be field-tested to be sure.
Re: #include C headers in D code
On Monday, 9 April 2018 at 11:48:51 UTC, jmh530 wrote: On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* [snip] Fantastic. This is so cool, I think it should be featured on the D blog as well (maybe when you get to your goal of having C++ features working consistently). More exposure is better exposure.
Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome
On Wednesday, 28 March 2018 at 20:50:51 UTC, Dmitry Olshansky
wrote:
On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote:
On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
- ability to write file during CTFE is not necessarily
positive. THough I can't tell why from the top of my mind.
The act of compiling a buggy program not influence the global
state of the computer. It should not be necessary to vet code
downloaded from the internet before even compiling it to
ensure it doesn't mess up the system.
The moment there is make or other build tool this is all futile.
CTFE should run in a sandbox. It must be safe to compile code.
I agree but mostly on the grounds of purity and
reproducibility. It also enables caching and incremental builds.
Safety - not so much.
Indeed, even without such high level tools using the linker is
dangerous due to issues that nobody wants to consider
vulnerabilities.
For demo:
$ mkdir test ; cd test
$ echo 'import std.stdio; void main(){ writeln("test"); }' >
test.d
$ ln -s shouldntexist test
$ dmd test.d
$ ls -l
total 760K
-rw-r--r-- 1 cym13 cym13 90 Mar 29 00:28 test.d
lrwxrwxrwx 1 cym13 cym13 13 Mar 29 00:33 test -> shouldntexist*
-rw-r--r-- 1 cym13 cym13 14K Mar 29 00:33 test.o
-rwxr-xr-x 1 cym13 cym13 740K Mar 29 00:33 shouldntexist*
This can easily lead to privilege escalation by creating
sensitive files in specific locations with arbitrary content
(~/.ssh/authorized_keys comes to mind).
Ok, this needs a specially crafted symlink, but it's one more
thing to check before compiling anything... Compiling just can't
reasonably be assumed to be secure (although I'd very much like
it to be).
Re: Ecoji-d v1.0.0 is released - Base1024 using emojis
On Thursday, 15 March 2018 at 18:45:51 UTC, Anton Fediushin wrote:
$ dd if=test.raw | gzip -c | wc -c
67108864 bytes (67 MB, 64 MiB) copied, 5.49022 s, 12.2 MB/s
67119122 # Raw files are terrible for compression
$ dd if=test.raw | ./ecoji-d | gzip -c | wc -c
67108864 bytes (67 MB, 64 MiB) copied, 27.9972 s, 2.4 MB/s
32178275 # 48% improvement
$ dd if=test.raw | base64 | gzip -c | wc -c
67108864 bytes (67 MB, 64 MiB) copied, 10.3381 s, 6.5 MB/s
68892893 # Pretty bad, yeah
Randomness isn't compressible. The fact that ecoji-d compresses
anything above 1% shows only that there is a bug in your library:
```
$ dd if=/dev/urandom bs=4K count=16K of=test.raw
16384+0 records in
16384+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 0.373423 s, 180 MB/s
$ dd if=test.raw | ./ecoji-d | gzip -c | gzip -cd | ./ecoji-d -d
> test2.raw
131072+0 records in
131072+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 24.9523 s, 2.7 MB/s
$ wc -c test.raw test2.raw
67108864 test.raw
11185155 test2.raw
```
So definitely not the same files before and after
compression/decompression. However the beginning is the same:
```
$ xxd test.raw | head
0010: a05f c801 bf01 13c1 04a2 556a 6d79 a09c
._Ujmy..
0020: 8032 523e 851d 419a b0d3 0c4f e7ba 93e1
.2R>..AO
0030: 9fdc 7c55 2645 f6e7 3f9e f5db bc92 1e29
..|U?..)
0040: 457a a3b9 c274 3b08 6bde 486a 1798 f281
Ez...t;.k.Hj
0050: 9d91 e97a f13f db8b 5d0c 114a 27be 2154
...z.?..]..J'.!T
0060: a9a2 3a17 36e4 9181 64f2 35b6 aa91 064d
..:.6...d.5M
0070: 863a ddbd 8776 f87d 3eb2 634f 12dc 6e7f
.:...v.}>.cO..n.
0080: 46c9 bc95 2620 b315 e84d 9ee4 8651 d172 F...&
...M...Q.r
0090: 836d 7bf8 9e1c 09c3 0e10 b787 7e06 bc39
.m{.~..9
$ xxd test2.raw | head
0010: a05f c801 bf01 13c1 04a2 556a 6d79 a09c
._Ujmy..
0020: 8032 523e 851d 419a b0d3 0c4f e7ba 93e1
.2R>..AO
0030: 9fdc 7c55 2645 f6e7 3f9e f5db bc92 1e29
..|U?..)
0040: 457a a3b9 c274 3b08 6bde 486a 1798 f281
Ez...t;.k.Hj
0050: 9d91 e97a f13f db8b 5d0c 114a 27be 2154
...z.?..]..J'.!T
0060: a9a2 3a17 36e4 9181 64f2 35b6 aa91 064d
..:.6...d.5M
0070: 863a ddbd 8776 f87d 3eb2 634f 12dc 6e7f
.:...v.}>.cO..n.
0080: 46c9 bc95 2620 b315 e84d 9ee4 8651 d172 F...&
...M...Q.r
0090: 836d 7bf8 9e1c 09c3 0e10 b787 7e06 bc39
.m{.~..9
```
So I think ecoji-d just truncates its input at some point.
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote: About a month ago, Sebastian Wilzbach sent an email out to a few of the core D folks asking for feedback on a survey he had put together. He thought it would be useful for the Foundation to use in order to make decisions about where to expend development efforts. Eventually Andrei gave his stamp of approval, the survey questions were tweaked, and then it was ready to roll. Of course I would love for you to read my blog post announcing it, but if you want to skip the prose and go straight to the good stuff, here's the survey link: https://seb134.typeform.com/to/H1GTak The blog: https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/ Reddit: https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/ If that were to be done again here are a few points that I'd improve: - there are many occurences of open questions where I entered a text only to find that the next fixed-choice question was about what I had written. I therefore feel like open questions should be asked as late as possible. - some questions introduce clear bias as they don't have a clear default exit path. For example for "How would you rate the importance of having documentation and error messages translated into your native language?" I feel like english speakers should have a way to exit cleanly as clearly they are both more numerous than the counter part (I think) and less likely to feel a need for supporting other languages. Similarly for the question "Would you or your company donate to the D Language Foundation (DLF)?" I feel like a "Maybe, I just don't feel like it right now" tag would have allowed distinguishing between people that actually don't have the money but would donate otherwise and people that aren't opposed to the idea but prefer donating to other projects for example. - I don't know if typeform allows it but sometimes having a link to the feature discussion or library reference would have been great. I didn't had to search many of them to actually know what the survey was talking about (which doesn't always indicate that I'm not concerned about the consequences of the change). That said, it was a very complete survey, thanks to everybody involved in putting this up! I hope it'll be of some use to the foundation.
Re: Vanquish Forever These Bugs That Blasted Your Kingdom
On Monday, 12 February 2018 at 04:30:38 UTC, psychoticRabbit wrote: On Sunday, 11 February 2018 at 15:18:20 UTC, Cym13 wrote: On the other hand, if my bank shoots itself in the foot it's with my money... We must definitely have ways to do it but it must be explicit and restricted to where it's useful. There is no need for -boundscheck=off in D. It is always possible to disable boundschecking locally, and that's a good thing. When was the last time a bank lost customers money due not checking bounds? It's far, far more likely you'll lose your money due to their dodgy lending practices (as many have already experienced). As someone who's job is to audit banking and governmental systems for security vulnerabilities, I can assure you it's a real issue. Not the most common one, okay, but that doesn't make it any less dangerous.
Re: Vanquish Forever These Bugs That Blasted Your Kingdom
On Sunday, 11 February 2018 at 15:11:55 UTC, psychoticRabbit wrote: On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky wrote: Other languages like Rust or C# (or Java) have bounds check. Plus we probably lose it in release mode, which is the mode where lurking bugs are discovered usually days after development ;) Some of these languages would prevent it on the VM level/compiler level, leaving no way to shoot yourself in the foot. We all really need to get away from this idea that *we* should stop *others* from shooting themselves in the foot. People are free to do it, if they want. Who has the right to take that choice away from me? So let's NOT be like those other languages that just want to control what you do. -boundscheck=off D rocks! On the other hand, if my bank shoots itself in the foot it's with my money... We must definitely have ways to do it but it must be explicit and restricted to where it's useful. There is no need for -boundscheck=off in D. It is always possible to disable boundschecking locally, and that's a good thing.
Re: dxml 0.1.0 released
On Friday, 9 February 2018 at 21:15:33 UTC, Jonathan M Davis wrote: [...] Of note, dxml does not support the DTD section beyond what is required to parse past it [...] - Jonathan M Davis Fun fact, since the most common security vulnerability associated with XML (XEE [1]) is based on exploiting the fact that most libraries parse in-line DTDs by default, this makes dxml immune to such attacks. Given how often this vulnerability is found in the wild it sounds like a very good thing to me :D [1]: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
Re: dlang-requetst: openssl 1.1 compatible release
On Thursday, 3 August 2017 at 18:04:33 UTC, Suliman wrote: Moving any third party code to std library have both "pro" and "contra" and it was discussed several times. From my point of view there is nothing wrong with modules outside of std library as long as these modules are visible to newcomers, well documented and have developer support. HTTP *very* important part in present time. Every modern language should have good native http-lib out of the box. I understand that it's can be done as outside module, but JSON also can be outside, and files can be outside. But I do not think that it's good idea. http-request is much more friendly and powerful than curl. It's much better to move curl as external package. I think it shouldn't be included in Phobos *because* it's a good library that we want to see growing. Let's compare with the case of the original Requests library, in Python. As it is the most downloaded Python library ever there have been discussions about including it in the standard library. After much deliberations Kenneth Reitz (the author) decided that integrating requests in the stdlib would harm it by imposing a slower release cycle not fitting the fast iterations needed by the package. Furthermore so many python programs need requests that most people get to install it one time or another, making it a de facto standard that is standard enough for its purpose. Clearly that decision did not slow Requests development, nor did it hit its popularity. People just do a "pip install requests" and don't care about it anymore. In D the situation is even easier because it is compiled: the developer is the only one having to add a line to its dub.json, the user doesn't have to care at all. And given that the package still has much room for improvement freezing it in Phobos doesn't strike me as a good idea at all. Of course Phobos must propose an HTTP interface, but it must propose one that allows you to build better ones, it doesn't have to propose a perfect one (although it would obviously be nice).
Re: dlang-requetst: openssl 1.1 compatible release
On Thursday, 3 August 2017 at 06:33:38 UTC, ikod wrote: Hello, Since version 0.5.0 dlang-requests has become compatible with both 1.0.x and 1.1.x versions of openssl library. Please try and report any issues on github. Thanks! dlang-requests is HTTP/FTP client library, inspired by python-requests with goals: small memory footprint performance simple, high level API native D implementation https://code.dlang.org/packages/requests https://github.com/ikod/dlang-requests Thank you very much for this, the openssl issue was a point I really wanted to be fixed :)
Re: The DLang Tour translated into French
On Friday, 23 June 2017 at 09:00:27 UTC, Quentin Ladeveze wrote: Hi everyone ! https://github.com/dlang-tour/english/commit/00b3bc164d315f95f8ac968d73947ebc10edc925 The DLang Tour is completely translated to french, yay :) Thanks to Patrick Schlüter and Olivier Pisano for the reviews, and thanks to Sebastian Wilzbach for the help. If you can read french, feel free to check it out ! https://tour.dlang.org/tour/fr/welcome/welcome-to-d Merci !
Re: Compile-Time Sort in D
On Friday, 9 June 2017 at 01:34:14 UTC, Mike Parker wrote: On Thursday, 8 June 2017 at 19:07:50 UTC, cym13 wrote: Seeing that the one and only D example in the nim article is a broken one (using static instead of enum or static immutable for 'b') we should have started with a correct example before showing the broken one... Good to know for next time. static variables are initialized with compile-time values. They don't need be immutable for that. My bad, I miscopied the code.
Re: Compile-Time Sort in D
On Wednesday, 7 June 2017 at 21:47:58 UTC, John Carter wrote: On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote: https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/ Seems like you have inspired people... http://blog.zdsmith.com/posts/compiletime-sort-in-nim.html Seeing that the one and only D example in the nim article is a broken one (using static instead of enum or static immutable for 'b') we should have started with a correct example before showing the broken one... Good to know for next time.
Re: Faster Command Line Tools in D
On Wednesday, 24 May 2017 at 21:34:08 UTC, Walter Bright wrote: It's now #4 on the front page of Hacker News: https://news.ycombinator.com/news The comments on HN are useless though, everybody went for the "D versus Python" thing and seem to complain that it's doing a D/Python benchmark while only talking about D optimization...even though optimizing D is the whole point of the article. In the same way they rant against the fact that many iterations on the D script are shown while it is obviously to give different tricks while being clear on what trick gives what. I am disappointed because there are so many good things to say about this, so many good questions or remarks to make when not familiar with the language, and yet all we get is "Meh, this benchmark shows nothing of D's speed against Python".
Re: Faster Command Line Tools in D
On Wednesday, 24 May 2017 at 13:39:57 UTC, Mike Parker wrote: Some of you may remember Jon Degenhardt's talk from one of the Silicon Valley D meetups, where he described the performance improvements he saw when he rewrote some of eBay's command line tools in D. He has now put the effort into crafting a blog post on the same topic, where he takes D version of a command-line tool written in Python and incrementally improves its performance. The blog: https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/ Reddit: https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/ A bit off topic but I really like that we still get quality content such as this post on this blog. Sustained quality is hard job and I thank everyone involved for that.
Re: Trip notes from Israel
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote: http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ -- Andrei Now that you are back and could take some time to think this over, would you say your trip will influence how you see D's and the D community evolution? In what way?
Re: DMD now has colorized syntax highlighting in error messages
On Sunday, 14 May 2017 at 19:11:32 UTC, Basile B. wrote: On Sunday, 14 May 2017 at 17:54:38 UTC, Jacob Carlborg wrote: On 2017-05-14 18:25, Walter Bright wrote: 1. print out the offending line I hope this one will be optional/configurable. I don't think it necessary to print the offending line within an editor/IDE. They usually can already map the error to the offending line. Yes +1 for configurable. IDEs already parse and make things clickable. It's not just +1, it's mandatory. If you implement this you must add a new compiler switch. Can't the IDE remove the line itself if it troubles him? I don't think such a small thing should burden the compiler with a flag just for the sake of a tool.
Re: Basil, Genesis, Patchup, Pendown and Pepss are now open source
On Sunday, 7 May 2017 at 11:29:08 UTC, Ecstatic Coder wrote: I have released five of my internal tools on Github under the GNU GPL, not only in the hope that they are useful to others, but also to indirectly promote the D language, in which most of them are implemented. https://github.com/senselogic These tools are : * Basil, a textual database builder (D). * Genesis, a generic source code preprocessor (D). * Patchup, a scriptable source code patcher (D). * Pendown, a lightweight markup for colored documents (JS). * Pepss, a SCSS preprocessor (D). All of them are implemented as single file scripts without external dependencies, to be easily compilable. Thank you!
Re: Introducing Diskuto - an embeddable comment system
On Wednesday, 15 March 2017 at 02:14:34 UTC, Sönke Ludwig wrote: Am 14.03.2017 um 21:56 schrieb Daniel Kozak via Digitalmars-d-announce: Dne 14.3.2017 v 21:24 Sönke Ludwig via Digitalmars-d-announce napsal(a): Did you delete the comments yourself? The time limit for deletion/editing currently isn't enforced on the server (ticket already open), so anyone can delete their own tickets currently at any time. I've noted the other issues and will tackle those tomorrow. I have deleted not only my comments, I can delete enyone comment Okay, that was supposed to be implemented before 1.0.0, but then I forgot about it: https://github.com/rejectedsoftware/diskuto/blob/d8376f3e54a03574f69af13a0b41b5e994b6ce44/source/diskuto/web.d#L107 You'll also want a CSRF token for that, checking that the user is the author isn't enough.
Re: [Slides] Generic Low Level Programming with D - The Better C for your Business
On Friday, 28 October 2016 at 06:46:27 UTC, Ilya Yaroshenko wrote: https://docs.google.com/presentation/d/1w1cQ8vDluglRIt8Qdnm-sY7kqxoKZxbPEWW6tR3lPpo/edit?usp=sharing Do you think you could maybe find the time to do a quick blog post to illustrate the slides? To be honnest the slides without the presentation aren't that clear or useful but I'd like to hear what you have to say.
Re: Article: Increasing the performance of D math code
On Tuesday, 11 October 2016 at 18:01:47 UTC, Johan Engelen wrote: On Tuesday, 11 October 2016 at 17:29:47 UTC, Ali Çehreli wrote: On 10/11/2016 07:01 AM, Johan Engelen wrote: > I wrote a piece on LDC's fastmath stuff that Mir uses for > high-performance D math code: > > https://johanengelen.github.io/ldc/2016/10/11/Math-performance-LDC.html > > cheers, > Johan Kind of off topic and hopefully constructive critism: You have sentence that starts with "I’m afraid it won’t be a nice read..." on Reddit. No matter how correct, there is no need to use negative marketing for your work. :) How about something more positive like "I'm sure you'll enjoy this more if you're familiar with...". ;) Something to keep in mind next time! I agree, be it only because I feel that even people with only vague knowledge of assembly and SIMD can benefit from this article. That was a nice read, thank you :)
Re: Cppcon tonight at 8:30 in Bellevue
On Thursday, 22 September 2016 at 19:50:40 UTC, Atila Neves wrote: On Wednesday, 21 September 2016 at 22:32:27 UTC, Walter Bright wrote: Wednesday 09/21/2016 8:30pm: Writing Secure C++ CppCon is being hosted at the Meydenbauer Center in Bellevue. Directions and parking information can be found here: http://www.meydenbauer.com/parking-directions/ Additional information on CppCon can be found here: http://cppcon.org/ Don't need a ticket to attend this one, all are welcome. I plan on being there. D's been explicitly mentioned in two talks that I've been to so far. Atila Which talks are those?
Re: dcompute - A library + ldc modifications - can now build a simple add kernel
On Sunday, 17 July 2016 at 07:45:45 UTC, Nicholas Wilson wrote: Available here[1][2], it can now build a simple add kernel for both CUDA (.ptx) and OpenCL (.spv) (and of course the host code) in one compiler invocation. A lot of things are still hardcoded and the optimisations need to tuned a bit more but it works. Any and all testing, feedback,bug reports and pull requests welcome! I'll be working on it the next two weeks, after which I go back to uni and will have less time to work on it, so the more feed back the better! [1]https://github.com/thewilsonator/dcompute [2]https://github.com/thewilsonator/ldc/tree/dcompute What did you have to modify in LDC? Was the change important? I'm asking because the lesser the change the more likely it is to be maintanable in the future and/or added to LDC as a proper extension.
Re: Button: A fast, correct, and elegantly simple build system.
On Sunday, 12 June 2016 at 20:03:06 UTC, Walter Bright wrote: On 6/3/2016 1:26 AM, Dicebot wrote: From that perspective, the best build system you could possibly have would look like this: ``` #!/usr/bin/rdmd import std.build; // define your build script as D code ``` Yeah, I have often thought that writing a self-contained D program to build D would work well. The full power of the language would be available, there'd be nothing new to learn, and all you'd need is an existing D compiler (which we already require to build). What about Attila's work with reggae?
Re: Reddit announcements
On Tuesday, 31 May 2016 at 19:33:46 UTC, John Colvin wrote: On Tuesday, 31 May 2016 at 18:57:29 UTC, o-genki-desu-ka wrote: Many nice announcements here last week. I put some on reddit. https://www.reddit.com/r/programming/comments/4lwufi/d_embedded_database_v01_released/ https://www.reddit.com/r/programming/comments/4lwubv/c_to_d_converter_based_on_clang/ https://www.reddit.com/r/programming/comments/4lwu5p/coedit_2_ide_update_6_released/ https://www.reddit.com/r/programming/comments/4lwtxw/compiletime_sqlite_for_d_beta_release/ https://www.reddit.com/r/programming/comments/4lwtr0/button_a_fast_correct_and_elegantly_simple_build/ https://www.reddit.com/r/programming/comments/4lwtn9/first_release_of_powernex_an_os_kernel_written_in/ I'm a bit concerned that people will react negatively to them all being dumped at once. Same here, moreover while some annoncements are about "ready to show" projects (button or powernex for example) others like "D embedded database" clearly are too young not to annoye /programming/ people IMHO.
Re: New Article: My Experience Porting Python Dateutil's Date Parser to D
On Thursday, 10 March 2016 at 21:25:16 UTC, Jack Stouffer wrote: On Wednesday, 9 March 2016 at 22:12:42 UTC, Walter Bright wrote: I haven't read the article yet, but you'll get more interest by putting a summary as the first comment on reddit. Thanks for the advice, I think it caused more people to read it. Also, I forgot to mention in the article that the unit tests with coverage reports enabled run in 110ms. I love fast tests :) Did you time the python tests too? A value by itself doesn't mean much to me
Re: https everywhere!
On Monday, 23 November 2015 at 21:18:58 UTC, Walter Bright wrote: The widgets don't, but the forums worked when I tried it. Firefox 42.0 here, neither the widgets nor the forums worked.
Re: PowerNex - My 64bit kernel written in D
On Saturday, 21 November 2015 at 11:34:57 UTC, Piotrek wrote: This is my general concern for all libs developed by the D community. IMO license other than Boost is very cumbersome and doesn't comply with the D core libs. Just re-read the boost license and it says nothing about incompatibility with other libraries written in other licenses. How would it be a problem then that the D core libs are licensed with boost and this program isn't? Heck, even the GPL is compatible! http://www.gnu.org/licenses/license-list.html#boost
Re: The D Language Foundation has $5000 to its name
On Tuesday, 17 November 2015 at 20:54:34 UTC, Andrei Alexandrescu wrote: Quite timely after the announcement of that $600K donation for the Julia language, I'm happy to announce that the D Language Foundation has a bank account seeded with $5000 - as I promised, it's a round-up of my last royalty check. The D Language Foundation doesn't yet have non-profit status, so we can't accept donations in that account; that'll take a few more months. I'll keep everybody posted. Andrei What do you plan to do concretely with that money? Advertise? Support projects?
Re: "Programming in D" ebook is available for purchase
On Wednesday, 28 October 2015 at 08:01:29 UTC, Ali Çehreli wrote: Although the book will always be free[1], many of you have expressed a need to pay without having to buy the paper version. It's a bit late now but I like what Cory Doctorow (a writter who publishes mainly books under Creative Common license) does: the epub/pdf version is free but if you want to participate without buying the paper version you can buy a book that will be given to a library (of your choice if you express one) instead. This allows participation as well as diffusion. As this is not a book of fiction it may be suited to fewer libraries but I still think this is a concept worth sharing.
Re: CppCon: Declarative Control Flow
On Monday, 19 October 2015 at 15:38:41 UTC, Andrei Alexandrescu wrote: It came up while I was traveling, someone posted it on reddit already (thanks): https://www.reddit.com/r/programming/comments/3pcwa1/the_comedian_strikes_again_andrei_alexandrescu_on/ Good motivation for, and examples of, using scope statements. Andrei A bit off topic but I've always wondered... Why are people calling you the comedian? Is that only because you make great entertaining talks?
Re: Blog post : OOP composition with mixins
On Tuesday, 1 September 2015 at 11:36:49 UTC, Dicebot wrote: On Tuesday, 1 September 2015 at 10:18:08 UTC, Luís Marques wrote: On Monday, 24 August 2015 at 11:10:16 UTC, Dicebot wrote: Rough summary of the talk I have given for recent Berlin D meetup event: https://blog.dicebot.lv/posts/2015/08/OOP_composition_with_mixins I'm having trouble resolving that DNS name. Technical server issues, should be back now. BTW, a bit HS but in your article about Rust (https://blog.dicebot.lv/posts/2015/01/thoughts_about_rust_from_d_programmer) there is a “” lying in the first example.
Re: Does the compiler check for safe?
On Sunday, 28 June 2015 at 07:49:41 UTC, Charles Hixson wrote: I took some code that was annotated safe, and modified it to use a buffer internal to the class, and an offset counter. Some of the routines adjusted the counter. I forgot to remove the safe annotation. It compiled without error. So... 1) The compiler didn't check for safety 2) It counts as safe if you only modify local-to-the-class variables (and I misunderstood). or 3) This error is only detected on execution But which? (I'm still writing the code, so I can't yet try to execute it, and I took off the safe annotation because after I read the definition in TDPL it seemed a mistaken annotation. But perhaps I misunderstand.) Please don't post in Announce for questions, Learn would be a better place. For your problem, reading the list http://dlang.org/function.html#safe-functions I'm not sure what is unsafe in what you do.
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 13:04:41 UTC, Vladimir Panteleev wrote: Gah, I'm late! Anyway, this is my hackathon project: http://digger.k3.1azy.net/trend/ Succinctly, it is the lovechild of Digger and Mozilla's areweslimyet.com. It measures stats about D built from D's entire GitHub history, as well as those of programs built with said D versions. Currently only two programs are tested (empty program and hello world), so please send PRs for meaningful benchmarks. Adding new programs is very easy: http://j.mp/1I7ELEc. There is a bunch of cool things happening under the hood about which I might or might not do a full blog post later. Currently it's still collecting data from recently added benchmarks, so coverage is spotty for some tests - should be fleshed out in a few days. Enjoy! I got a parsererror for data/data.json, Unrecognized token '?'
Re: Quick Start with D: few examples and set of links.
On Friday, 1 May 2015 at 08:18:10 UTC, Ilya Yaroshenko wrote: http://d.readthedocs.org I hope this examples will be useful for students. Ilya Showing how easy interacting with python can be is a very good idea, and doing so by dealing with scientific data is an even better one!
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 12:21:01 UTC, Ola Fosheim Grøstad wrote: On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). There are many alternatives to Python. Like Nim or Dart: https://www.dartlang.org/articles/beyond-async/ https://www.dartlang.org/articles/await-async/ Nim seems quite interesting indeed, even if I'm not sure how well it scales. It looks like a language that is prowd of a heavy use of macros and DSL definition à la lisp. I know lisp enough to know that it's not a problem in itself, but that it should be developed wisely. It may look at first as a better alternative than D for a pure python developer, but I'll stick with D. However, I can't see a pythonista being excited in Dart at all, at least not for what he finds in python. More restricted in any way, no clear functional orientation possible, a clear lack of expressiveness... D clearely has the advantage there.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like or web server developments with vibe.d thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal Writting Python in D. Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :)
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 21:45:23 UTC, Walter Bright wrote: On 3/29/2015 12:09 PM, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html Has someone reddit-ized it? It seems so: http://www.reddit.com/r/programming/comments/2tqiaj/d_is_like_native_python/?submit_url=http%3A%2F%2Fbitbashing.io%2F2015%2F01%2F26%2Fd-is-like-native-python.htmlalready_submitted=true
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Sunday, 29 March 2015 at 21:06:28 UTC, Laeeth Isharc wrote: On Sunday, 29 March 2015 at 19:44:01 UTC, cym13 wrote: On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like or web server developments with vibe.d thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal Writting Python in D. Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :) should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python I just seen what you did in the wiki, that's great! I don't have much time to invest tonight but I'll definitely do my part of the job in a day or two.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wednesday, 25 March 2015 at 23:00:32 UTC, bearophile wrote: Ola Fosheim Grøstad: Downplaying other languages makes the D crowd look desperate... That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best). Bye, bearophile I don't know about that... I too think that maybe it was a clumsy way of doing it but I'm not sure that we would have had such critics if Python (eg.) had been choosen to write the examples, even with not very pythonic code. Maybe it should have been backed up with another language not to put the comparison on D alone. Bad publicity is better than no publicity in many cases. There's no reason why this couldn't play out right in the end.
