Re: How to initialize a associative array?
On Saturday, 24 December 2016 at 11:21:11 UTC, Stefan Koch wrote: You cannot initialize an AA at compile-time. Because AA's are provided by druntime and the ABI is not stable. This bit me when I was first starting out as well. I feel like there's really very little documentation on this, and I think most people's expect that you'd be able to initialize AAs from literals at compile time, just like normal arrays. Does anyone know if compile-time initialization of AAs is something that will be fixed?
Re: Our docs should be more beautiful
On Monday, 18 July 2016 at 15:56:29 UTC, Andrei Alexandrescu wrote: I was proofreading http://dtest.thecybershadow.net/artifact/website-f26d7179b8449e89e1961391fde9f221813c707c-04d0496c2d8cecedc4d75c919646d564/web/phobos-prerelease/std_experimental_checkedint.html and there are a few ways in which our docs could look better. * My pet dream was to work on a project with a beautiful justified and hyphenated website. After endless debates, ugliness has won - I'm looking at a eye-scratching ragged right edge. * The constraint on "struct Checked" is not formatted the same as the other constraints. * Vertical spacing is just too fluffy. Looking e.g. at the docs for "Payload" and "hook" - each has a short description. The vspace between definition and description is too tall. The vspace between the description and the next definition is too tall. The grayed space within which the definition itself sits has too large up and bottom margins. The vspace above "Jump to:" is too high. Literally all vertical spacing is larger than it should be. * The red vertical line on the left of each definition is meh. There's a bit more sense for struct definitions because of the "Jump to:" real estate. But for each little one-line definition, the red bar is just odd. Also, there is no change in color as indentation goes in (which would be a useful cue for long struct definitions). * I don't see a point to the boxes within which each definition + its comments sits. Then there's one more box for the example! Boxes, boxes everywhere, and nary a drop to drink. They'd make sense e.g. if one could collapse a box. As such - hey, they just add more vspace :o). * The vspace between the ditto'ed definitions "enum auto min;" and "enum auto max;" is again too large. * The grayed out constraints are also indented horizontally - by a lot. If they're already distinguished by color, no need to indent them. Oh, then I saw if you hover you see "Constraints: " written in the space that seem to be indentation. Could we format that in non-code font at least? * Spacing between doc paragraphs (see e.g. doc of opCast) seems to be 80% line height. Should be 50%. * The enumerated items (see doc of opChecked) seem to be the only artifact that's properly spaced vertically. I guess nobody discovered them so they're at the system default. * "0 Contributors" should not be displayed at the bottom if there are no contributors. But I assume that's only the case before the pull is merged? Andrei I'm not going to get involved this round of bikeshedding, (except to say that yes, the docs are far from perfect, and also that justification/hyphenation on the Web is a mixed bag, and right-ragged with a good line-length is a fine and robust solution). But I'd like to give some resources for reference. Racket's docs have actually been designed by a professional typographer, so might be a good reference point. Example: https://docs.racket-lang.org/reference/flonums.html And that the same person has an excellent online resource for typographic style: http://practicaltypography.com/ And it's good to have something like that (no matter if it's somewhat arbitrary) to decide these kinds of endlessly debatable issues. (Notice the site is left-justified/right-ragged :)) "Keep in mind that the justification engine of a word processor or web browser is rudimentary compared to that of a professional page-layout program. So if I’m making a word-processor document or web page, I’ll always left-align the text, because justification can look clunky and coarse. Whereas if I’m using a professional layout program, I might justify." (http://practicaltypography.com/justified-text.html)
Re: Using information from the dlang sit
On Friday, 8 July 2016 at 07:32:30 UTC, celavek wrote: On Thursday, 7 July 2016 at 14:14:01 UTC, Seb wrote: Your project (an open source platform for programming exercises) looks very nice. I don't see any problem in using information from dlang.org - especially for teaching D to newcomers. Most of the content is licensed under the Boost license, however if you are in doubt you should ask Andrei and Walter. They can speak for the D Language Foundation. Btw you should also have a look at tour.dlang.org and Ali's excellent book: http://ddili.org/ders/d.en/index.html Thanks for the pointers. It is not my project. It was started by Katrina Owen. I'm trying to get involved and as I'm also learning D I was thinking it would be a good idea to jumpstart the D track there. I was planning to use the info from the D "tour" pages to fill some basic doc required by the sit. I've also seen Ali's book and I find it excellent. I think this is a great idea. I've used exercism with several languages and had a lot of fun. I did some work making a D track a while ago, but let it fall by the wayside. One thing you should do if this goes live is promote it here and encourage people to participate. Exercism really shines if there are active nitpickers (their name for code reviewers) commenting on people's answers. If some of the champion helpers in the Learn forum here participated on the exercism track, it would really help to make it successful, and encourage newbies.
Re: Vision document for H2 2016
On Thursday, 7 July 2016 at 19:56:29 UTC, Andrei Alexandrescu
wrote:
On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:
https://wiki.dlang.org/Vision/2016H2 -- Andrei
Please provide feedback. We'll make a couple more passes before
this is complete. Thanks! -- Andrei
This list is full of good and worthy stuff, but is very long.
Most of this won't be done in 2H16, so calling these "2H16
priorities" is misleading, and doesn't give a good impression.
For someone who really know where the language is headed, there's
no sense of what will really be done in the next six months, what
is in progress and might be done, and what stuff is just wishful
thinking. The fact that so much is just copied over from last
half says it all.
Some of these, especially the marketing, are evergreen tasks.
("Promote books and articles"). If there's something concrete you
have in mind for 2H16 say it, otherwise, it belongs somewhere
else.
This is a really good long-term vision list, and it might be
better labeled that, with different items slated for expected
realization (2H16, 1H17, "Who knows?"), etc. (Links to associated
bug reports would be useful too, so we know what's being worked
on.)
In general, I feel like a list like this should actually be
achievable. There's a silly, but still useful, business thing
called "S.M.A.R.T." goals: Specific, Measurable, Attainable,
Realistic, and Timely. This ain't that.
Re: Accessing types by context
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker
wrote:
Suppose one has void test(myEnum e)
enum myEnum
{
A,B,C
}
[...]
Doesn't the with statement solve your problem here?
with (myEnum) {
test(A);
test(B);
test(C);
}
Re: Let's make the DLang Tour an awesome landing page for D newbies
On Thursday, 23 June 2016 at 19:24:49 UTC, Seb wrote: Let me start with the good news: since the DLang Tour was launched by André last month, we had about 3K unique visitors and continuously have between 100-200 visitors per day. However here are the bad news: We loose about 40% of all visitors directly on the front page and we loose the majority (>70%) on the first ten pages. Our DLang Tour is the starting point for newcomers. Hence if you think in terms of Andrei's first five minutes, we loose pretty badly! One thing that might encourage having people move further along is to set up the interactive code sections as "quizzes." I.e. have the visitor fill in code to give a certain output or pass a unittest instead of just having a pre-written example. This makes the tutorial more interactive and fun. If this is geared towards real newcomers (not just c/c++ converts who are looking for quick reference), then I agree with Ali that less text per section (even if you need lots more bite-sized sections) would be best. If you look at the interactive tutorial on e.g. haskell.org, it moves in VERY small bits -- typing in math, sorting a list, etc. If even Haskell is going to break things down so simply, surely we can too. :)
Re: Let's make the DLang Tour an awesome landing page for D newbies
On Thursday, 23 June 2016 at 20:25:17 UTC, Carl Vogel wrote: The main one is no visible TOC. The only way to move around the tour is to go forward or backward one by one---making it hard to skip around, or understand what topics are coming up. A div on the side with all the section links would be great. Just to follow up, I realize there's the nav bar at the top. But it doesn't give the same sense of place or order as a vertical hierarchical TOC does.
Re: Let's make the DLang Tour an awesome landing page for D newbies
On Thursday, 23 June 2016 at 19:24:49 UTC, Seb wrote: Let me start with the good news: since the DLang Tour was launched by André last month, we had about 3K unique visitors and continuously have between 100-200 visitors per day. However here are the bad news: We loose about 40% of all visitors directly on the front page and we loose the majority (>70%) on the first ten pages. Our DLang Tour is the starting point for newcomers. Hence if you think in terms of Andrei's first five minutes, we loose pretty badly! We already tried to improve things a bit (slicker design, D-man on the front page), but we need your help to motivate future D-eists and inspire them! Last week we split the tour in individual Markdown files per chapter, s.t. improving the tour is only a button click away. I don't think you're going to solve this problem with better content for the tour--since people aren't even really getting to the content. Also, losing people after 10 pages doesn't sound that bad. I wouldn't expect people to go through the whole tour in one sitting. Nonetheless there are a couple of things that make me bounce. The main one is no visible TOC. The only way to move around the tour is to go forward or backward one by one---making it hard to skip around, or understand what topics are coming up. A div on the side with all the section links would be great. Also, while the live code window in the browser is neat, it breaks up the flow of the page, and I feel like I'd usually just prefer inline un-editable text. (E.g., what are you really going to experiment with in the Hello World script here? http://tour.dlang.org/tour/en/basics/imports-and-modules) These are just my opinions, and I don't claim to be representative of the audience you want to attract. Overall, I think this is a fantastic project. Thanks to all who've been working on it!
Re: Constraining template with function signature
On Thursday, 9 June 2016 at 19:08:52 UTC, cy wrote:
But it's probably clearer to use that is(typeof({ how this
function will be called })) trick.
A very delayed thanks to both of you. It does seem like it would
be useful to have something like a hasSignature!(Fun, Ret,
Args...) defined in std.traits. But Steven's solution is pretty
good.
Thanks again!
Constraining template with function signature
Hi,
What's the best way, when using a Callable as a template
parameter, to constrain it by signature?
For example, if you have a function that sorts an array like so:
T[] sortArray(alias less, T)(T[] arr) { ... }
Then you know that you'd want `less` to have signature (T, T) ->
bool.
Now, I can use something like isCallable std.traits to make sure
the predicate is a Callable, and there are various function
traits in the module that I could combine with `is` clauses to
enforce the signature it seems, but that seems very clunky. Is
there a better way?
I note that I don't find many examples of this in phobos, so I'm
wondering if there actually is a good solution...
Thanks,
-c.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 20:28:47 UTC, poliklosio wrote: On Monday, 6 June 2016 at 15:06:49 UTC, Carl Vogel wrote: (...) Also, the idea that more people will adopt D if you just "get rid of the GC" ignores the fact that you don't just "get rid of the GC," you replace it with another memory management scheme (manual, RAII, RC). If you replace all the parts of the language and phobos that rely on GC with, e.g., a poor implementation of RC, then you're just going to get another round of complaints, and no real adoption. I think you are going to get some adoption it you replace good GC with clunky RC. The key difference is a call to a function that uses GC is incomplete: some of it will execute later, after the call has finished. On the other hand a call to an equivalent function that uses RC has only local (in time) consequences: once you finished the call, it stopped executing. If it returned something that needs to be freed later, you know what it is. Of course people can write arbitrarily messed up things like singletons etc. but I'm not counting those because good libraries are usually free of those. This means you have control over all the OTHER code, however inefficient the call is. Hence, the second is acceptable in low-latency code, but the first is not. I get that and agree. My point was a different one -- that these conversations are about a totally hypothetical RC implementation that we all imagine is perfect, and so we just discuss theoretical GC vs RC tradeoffs. The real one that gets made is going to have bugs and unexpected corner cases. So the risk is that at some point we'll all run to reddit and say "Tada, no more GC" and folks will then just say "D has RC, but it's buggy and unreliable and doesn't work when [insert anecdote]" Maybe that won't be so---maybe the new memory management regime will be perfect and elegant and have no nasty surprises. But I feel a real "grass is greener" sense, when as many other has pointed out, the current GC could use a lot of love, which would solve problems for a lot of current users.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 09:16:45 UTC, Walter Bright wrote: On 6/6/2016 1:15 AM, Russel Winder via Digitalmars-d wrote: * Safety has holes and bugs. Then so does C, C++ and Rust, so this is just a comment made because it can be made and sounds bad. Bad enough to salve the conscience of the speaker as to why they are not already using D. It's pretty clear when they say that, and then continue using C++ which has no safety, that safety isn't the real reason. Reminds me of an anecdote Andrei is tired of. In the 80s, a C++ developer said that compilation speed, speed, speed is the most important thing in a C++ compiler. This went on until it was pointed out to him that he was using Microsoft C++, which was the slowest at compiling by a factor of 4. Clearly, what was actually most important to him was a name brand compiler (social proof), but he needed a more palatable reason, so he just latched on to one without much thought. We have to be careful about being led down the garden path by people who say "I'd use your product if only it did X." I have a lot of experience with that, and it's very rare that they'll use it if you do X. They'll just respond with "yeah, ok, but what I really need is Y." This process never ends. Sometimes it's because they're embarrassed by the real reason, sometimes they just take pleasure in you dancing to their tune. Paying attention to our existing users is a much more reliable source of information. I think this is a really important point and I 100% agree with Walter. Also, the idea that more people will adopt D if you just "get rid of the GC" ignores the fact that you don't just "get rid of the GC," you replace it with another memory management scheme (manual, RAII, RC). If you replace all the parts of the language and phobos that rely on GC with, e.g., a poor implementation of RC, then you're just going to get another round of complaints, and no real adoption. In my experience, GC complaints are split between existence and implementation. Some folks are dead against and GC code, others just don't like how the current GC works. In my world---which is not AAA gaming or HFT, but is still very concerned with performance---a GC is tolerable, but a clunky stop-the-world GC with big unpredictable pauses is less so. Having a high quality GC that can be avoided (with some agreed-to and well-documented limitations) would be great. My concern is that the kill-the-GC craze is going to fall into a second-system trap, and be replaced with buggy half-implementations of, say RC, that I can't rely on, or will be combing through piles of stale bug reports about in 6 months. I believe a big issue for D, and for any not-mainstream language, is being straight about what works and what doesn't. D is not alone in this, but I often feel I'm sold on features that I later find out are not fully implemented or have big holes in them. The limitations themselves aren't the problem---the trust is the problem. I never know if I can tell someone else "D can do that" safely (turning off the GC is a good example---it took me weeks of reading forums and documentation to see how practical that really was after initially reading that it was straightforward.)
Re: [OT] Things I like about Andrei
On Friday, 3 June 2016 at 02:17:51 UTC, Adam D. Ruppe wrote: A lot of us, myself included, have been very critical of Andrei lately but I want to list of the excellent work he has done over the years: First, early D was very different to D of today. Andrei changed that, for the better. He's a genius of innovation with templates and good at getting to the bottom of generic code. The Range concept is excellent, the logical extension of iterators like slices are to pointers, and std.algorithm is generally brilliant. Many of the patterns we take for granted in D, from templates in general to conversion and literals on top of them, to ranges and algorithms, were principally designed and implemented by Andrei. std.experimental.allocator is very well done and the Design by Introspection is not just smart insight to the generic programming problem, but actually explored and explained in such a way that we can hook onto it. His talks and writing are amusing and informative, and his dedication unquestionable. Andrei Alexandrescu is a very good, innovative programmer and writer who invents and explains things that others can't even consider. We're lucky to have him with us! I bought TDPL on sale whim a year ago, without any real interest in using D--just curious what it's deal was. And I think I devoured the whole thing in two evenings. It's one of the best books about a programming language I've read. I learned a lot from it---not just about D, but about language design and programming as well. And it's just funny as hell. Between the book and his talks, he's a great representative for the language. Like many folks, I only use D for hobby projects, and I could drop it at any time. I find the things that keep me excited about it are things I've read or heard from Andrei.
Runtime.loadLibrary linker errors
Hi, Whenever I try to compile code that relies on Runtime.loadLibrary, I get a linker error during compilation. ``` Undefined symbols for architecture x86_64: "_rt_loadLibrary", referenced from: _D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv in ll_test.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) --- errorlevel 1 ``` I'm using dmd 2.071 and ldc 0.17 on OS X. I've seen comments and some indications in the source that this function isn't available on OS X, but it's not entirely clear (forum threads are old, and the source in runtime is a bit over my head.) If this code won't compile on OS X, is there an alternative? Thanks, -c.
Re: Does D supports REPL
On Wednesday, 25 May 2016 at 19:38:42 UTC, jmh530 wrote: On Wednesday, 25 May 2016 at 00:55:52 UTC, Carl wrote: It's worth noting that some of those Jupyter kernels are pretty quirky/limited. For example in the C kernel, every cell is an isolated program with a main function. Which is not to say it wouldn't be great to have D integration, just that it's trickier than it may seem at first glance. I haven't used the C one. It looks like it is based on GCC. Cling is another one listed for C++. I haven't used Cling, but the example looks like the information in one cell can be used in later cells: https://github.com/root-mirror/cling/blob/master/tools/Jupyter/kernel/cling.ipynb There seems to be some decent documentation on creating kernels: http://jupyter-client.readthedocs.io/en/latest/kernels.html Yeah, I haven't tried the cling kernel yet, but it looks great. That's backed by an actual repl though. So it seems like that's a prerequisite for having a good Jupyter integration. This is a nice intro to the Jupyter architecture from the person who made the IHaskell kernel: https://www.schoolofhaskell.com/school/to-infinity-and-beyond/older-but-still-interesting/ihaskell
Re: Does D supports REPL
On Wednesday, 25 May 2016 at 00:12:24 UTC, Seb wrote: On Tuesday, 24 May 2016 at 23:26:27 UTC, jmh530 wrote: On Tuesday, 24 May 2016 at 20:44:57 UTC, Seb wrote: Maybe we just need to move it to the dlang github namespace, s.t. it gets properly maintained and maybe even released with dmd/dub? Integration with Jupyter would be cool as well, but I have basically no idea how to accomplish that. Yep I would love to have a D Jupyter kernel - there is already PydMagic [1], which looks great (I haven't tried it yet), but all those other languages (C, C++, Scala, Java, Tcl, Brainfuck, Clojure, Ocaml, Erlang, Go, FSharp, Haskell and on the dynamic end: Python, JavaScript, CoffeeScript, Ruby, PHP, Perl, Octave, Bash, PowerShell, Lua, Julia, Prolog, J, etc.) [2] managed to get a working Jupyter kernel, so why don't we :O I opened an issue at d-repl [3], maybe that's a good place to start a focussed discussion. [1] https://github.com/DlangScience/PydMagic [2] https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages [3] https://github.com/MartinNowak/drepl/issues/37 It seems to me that both drepl and dabble are unsupported. It's not clear to me which one at this point is a better basis for a stable repl (I kind of prefer drepl, since the code is clearer to me, and I can mostly compile it.) If you're really interested in a good REPL for D--which I agree would be a great gain--and want to fork either of these, I'd be very interested in this effort and happy to contribute (otherwise I may start going at it on my own). It really is something I'd use a lot if it existed.
Re: matrix library
On Monday, 23 May 2016 at 07:28:20 UTC, Vlad Levenfeld wrote: https://github.com/evenex/linalg I've some heard people (including me) asking about matrix libraries for D, and while there is gl3n it only goes to 4x4 matrices and was written before all the multidimensional indexing stuff. So I was using gl3n for awhile until I needed some 6x6s and threw together a syntax-sugary sort of wrapper over std.experimental.ndslice and cblas for matrix math. You can slice submatrices, assign to them, and perform ops on them with other matrices or 2-dimensional array slices... though, for implementation-ish reasons, ops involving 2-d arrays are elementwise (you'll have to call the Matrix constructor to use matrix multiplication again). It was built in kind of an ad-hoc way and I will be adding stuff to it as the need arises, so there's nothing there yet beyond the bare basics and you should expect bugs. All the matrices hold static arrays because I don't want to mess with reference problems right now. A matrix past a certain size will be more efficient to store as a dynamic array, of course. But, right now, I need this to make writing linear algebra code comfortable for myself rather than try to win at benchmarks. Bugs/Pull/Feature requests welcome. This is nice! I recently found myself having to make ad hoc lightweight matrix classes that wrap some blas functions. Making the dims template/compile-time params is an interesting choice, but I wonder if it is unduly limiting. How does what you're doing compare to what's in https://github.com/DlangScience/scid/blob/master/source/scid/linalg.d ? While that project doesn't have a ton of manpower behind it, it does seem like it's actively maintained, and they have brought in a ton of the lapack/blas headers already. It would be nice, and I think do-able, to have a relatively complete and performant library for matrices/ndarrays, especially given the recent work on ndslice. (If there are plans or a roadmap for this sort of thing, I'd love to contribute, and it seems from this announcement that others are interested also.)
D performance in Julia microbenchmarks
Hi -- first-time poster, long-time lurker... On its homepage, the Julia langauge (http://julialang.org) advertises some microbenchmark results to show how competitive it is with C, along with a number of other languages (go, python, JS, R, etc.). These should of course be taken with a big grain of salt, for the usual reasons (the implementations differ across languages, even at the algorithmic level, whether these are representative of real-life perf, not really rigorously timed, etc.) I implemented these in D and found it did really well across all of them (no great surprise, but good to see). The results are at the bottom, in absolute time and time relative to C. (note the infinite relative times are b/c the cc -O3 basically optimized the computation away) The github code is here: https://github.com/carljv/julia-perf I think it'd be good advertising to make a PR with these to the Julia repo and see if they'll put them on the site. A lot of people we drawn to Julia because it was making promises similar to D -- C-like performance in an easy-to-use language (in Julia's case, dynamic) with good metaprogramming (in Julia's case, AST macros). But I'd be thrilled if anyone---esp. those with D science/numerics knowledge---would be willing to take a look. E.g., I'm rolling my own matrix operations wrapping blas functions because I couldn't easily find the functionality in scid, mir, etc., but feel like I'm missing something. And I think while showing easy C ffi is great, showing that you can do this easily with a library would be good too. I'm also a bit of a D novice, so may be leaving some performance on the table. (Note though that I am trying to keep the code roughly inline with the Julia implementation and not using, like ASM or uglier perf hacks. It'd be nice to show off how D gives you high-level constructs with speed, not just writing the C implementation in D.) If you want to replicate these, the README on the repo should be relatively complete/correct about setting up and running. Please let me know if you're interested in this and have any questions or issues. FIB: dlang/ldc2 0.01ms infx go0.05ms infx julia 0.06ms infx python 3.56ms infx MANDEL: dlang/ldc2 0.13ms 1.22x go0.19ms 1.84x julia 0.20ms 1.88x python 3.97ms38.19x PARSE_INT: go 0.15ms 1.06x julia 0.18ms 1.23x dlang/ldc2 0.18ms 1.25x python 2.68ms18.75x PI_SUM: dlang/ldc2 2.91ms0.40x julia 7.27ms0.99x go8.40ms1.14x python 819.50ms111.10x QUICKSORT: dlang/ldc2 0.21ms 0.55x julia 0.37ms 0.96x go0.48ms 1.25x python 14.53ms37.73x RAND_MAT_MUL: dlang/ldc2 29.65ms 0.71x julia 49.88ms 1.19x go 68.84ms 1.65x python 71.95ms 1.72x RAND_MAT_STAT: dlang/ldc2 8.11ms1.26x julia21.99ms3.40x go22.00ms3.40x python 118.10ms18.27x
