Re: D Management Site
On Wednesday, 28 January 2015 at 11:18:46 UTC, Dicebot wrote: Maybe it is worth duplicating to dmd-internals mail list and with CC to those who actively contribute to DMD. To be honest I don't even know who is currently in active D development team. In this thread I see Andrei and Vladimir but neither seem very enthusiastic. Why not use #d-internals instead on IRC + searchable botbot.me logs for communication and brainstorming?
Re: How to copy object of class A to another object of class B?
On Wednesday, 28 January 2015 at 11:30:13 UTC, Marc Schütz wrote:
On Wednesday, 28 January 2015 at 09:44:29 UTC, zhmt wrote:
It is boring coding, I want a solution to copy them
automatically:
void copyObj(SRC,DEST)(SRC src,DEST dest)
{
foreach (i, type; typeof(SRC.tupleof)) {
auto name = SRC.tupleof[i].stringof;
__traits(getMember, dest, name) = __traits(getMember, src,
name);
writeln(name);
}
}
Unfortunitely, it doesnt work, how to improve it?
Haven't tested it, but the `auto name = ...` part is likely to
be the problem. By using `auto`, your declaring a runtime
variable, which you then later try to use with
`__traits(getMember, ...)`, which expects a value known at
compile time. Try using `alias name = ...`, or if that fails,
just repeat the expression `SRC.tupleof[i].stringof` wherever
`name` occurs (though I'm sure there is a nicer way).
And if the alias doesn't work directly, you can always use a
well-known hack:
alias Alias(T) = T;
alias Alias(alias T) = T;
so then this works:
alias member = Alias!(__traits(getMember, Parent, child));
Idk if it's a feature or a bug of how getMember works but I had
to use this numerous times.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Tuesday, 27 January 2015 at 09:07:30 UTC, tn wrote: On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu wrote: On 1/26/15 12:30 PM, Dicebot wrote: We couldn't merge it into std.experimental before because you have stated that even std.experimental modules shouldn't have a breaking changes normally. It was 2 reviews ago. Now you have reconsidered, which is understandable considering how long has it been taking, but pretending that was intended to work that way does not make you look good :( PS I was in favor for very lax initial requirements for experimental packages for this very reason. Now I remember. I admit I was wrong. -- Andrei I thought the idea was that there should be no _known_ pending breaking changes when mergin into std.experimental. Thus std.experimental would be for fixing problems that are found when the package is actually used. Breaking changes for fixing those would be perfectly fine. 1. review = if problems found = fix all known problems and repeat the review 2. once everyting seems ok in review = merge to std.experimental 3. if a new problem requiring a breaking change is found = fix it 4. once no new problems have been found for a while = seems ok = merge to std 5. if a new problem requiring a breaking change is found = can't fix it, maybe try to cirmumvent it somehow etc. (no breaking changes unless it's critical) I found out I quite like the Rust's way of doing this because it's changing so much and so fast -- plain and simple, unstable features are put behind feature gates and the only way for the end user to use unstable API is to explicitly mark it as allowing the unstable code. This also goes well with RFC review process. Once the feature is stabilized, no changes to user code are required, no imports to be changed etc. This allows them to merge in ridiculous amount of PRs/day and test everything out live without affecting the core stable API.
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Friday, 23 January 2015 at 17:19:44 UTC, H. S. Teoh wrote: OTOH, do I hear the cry of a volunteer? ;-) (I'm only half-joking... the thing is, if nobody steps up to write said tutorial, it isn't gonna materialize. The rest of us are already busy enough with whatever it is we're contributing to D. I could try in my spare time but I don't think I qualify as a D guru since there are some shady D areas I have yet to learn properly myself. It has to be a collaborative effort. On Friday, 23 January 2015 at 17:19:44 UTC, H. S. Teoh wrote: Having said that, though, I thought Ali's D book is pretty good in terms of serving as a beginner's tutorial to D? Or do we need a different one more geared towards seasoned programmers? (Ali's book is primarily targeted towards newbie programmers).) Ali's book is VERY good. The best part is that you can load it on Kindle / tablet / whatever (I did!) and take it with you. However, it's _not_ an official 30 minutes to D guide. It's more like 1 month to D if you survive it because it's very thorough and detailed. Come on, it's a bit too boring to only get to a for loop in chapter 10 if I'm just excited to see what the language is all about. For instance, I'm fairly certain that metaprogramming (at its simplest) should appear early in the guide. Yeah I've run into the same problem. Google search does not eliminate the need for a proper, well-thought-out, navigable index. I'm thinking perhaps an autogenerated alphabetical index of all symbols might be in order here? Yep, see my post above re: the incremental index. It's absolutely doable with DDOC / client-side JS. Easy. We pick a suitable beginner's tutorial -- either Ali's excellent book or something you or some other volunteer writes up, and put a big fat link to it in a prominent place on the front page. Problem solved. The problem is - I don't think we actually have one. And it really has to live on dlang.org to feel official and up to date. It has to be reasonably succinct but exciting, not too formal, well-styled, with links to official docs and read more there and there anchors. If you're not happy with Ali's book, please contribute your own. I'm pretty sure the dlang.org maintainers will be more than glad to include it. I (personally) am happy with Ali's book of course! But as I've already said a link to the book != a proper _official_ introduction. It could largely overlap though, that's true. Would you like to step up and spearhead this effort? Not alone by myself, that's for sure :) Ideally, someone who's already done a considerable amount of work on a book / docs, of course... Good! So let's see the PR's. :-) This needs to be well thought through :) But if noone objects to the style of Rust by Example which I tend to like -- perhaps we could come up with something similar (and perhaps more interesting, especially when it gets to all the metaprogramming jazz).
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Friday, 23 January 2015 at 17:03:17 UTC, aldanor wrote: Since we are the ones who generate the docs, we can totally do this (in a simplest way, bake in the markers into the ddoc and generate a javascript hashmap to trace back to them). I turns out that's exactly how it's done on the rust website, poor man's index engine :) http://doc.rust-lang.org/search-index.js -- DDOC can totally generate something like this, just a huge dict of markers. Once this is done, the client-side is quite easy.
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Friday, 23 January 2015 at 18:17:30 UTC, H. S. Teoh wrote: Well, to be fair, the reason Ali's book is so detailed is because it's geared towards the newbie programmer who is learning how to program, possibly for the first time. So the pacing isn't really suited for an experienced programmer who just wants to learn D as an additional language. The material is excellent, no doubt, but probably needs repackaging to target the seasoned programmer. Agreed. I think that's exactly the target audience (and exactly the one that we are missing the proper docs/guide for). After all, D is not a learn me a ruby in 15 minutes kind of language, so the chances are whoever's coming here has a vague idea of what they expect or what they want to learn about D. Just as an example, I've heard a lot of D talk on #rust-offtopic irc -- those folks would barely qualify as beginner programmers. I vote for ddoc / static generation. The site itself is static anyway, using client-side JS to do this seems to be overkill. You need both. What I meant was that DDOC has to be able to generate an index (one huge dict) and store that in a text file/json. The client-side would just use that database to provide on-site incremental search. Quite easy. If we don't have one, then the obvious first step is to begin writing one. :-) And when I said you should spearhead this effort, I don't mean you should do everything yourself. That's not feasible for obvious reasons. Rather, the community can and should help -- but you do need to take the lead in the effort, otherwise there will be no focused direction and things will go nowhere after 2 months. For example, you could come up with an initial draft or proof-of-concept and put it in a github fork where people can submit PRs to flesh out the skeletal ideas / outline you lay down as a first stab. Then you can solicit for feedback -- that's part of the role of spearheading the effort -- and oversee the overall direction. That way it's not just you who's put on the spot to do everything, but everyone can contribute and make it better than any single one of us can by ourselves. Or, for an even less daunting start: start submitting PRs for draft tutorial pages and code examples, and encourage others to do the same. Nothing gets things moving more effectively than having actual code / docs sitting in the PR queue ready to be merged. OTOH, too many forum threads (well-intentioned, mind you) tend to just fizzle out after a while and nothing gets accomplished. Thanks for clarifying. I too hope this thread doesn't just become another bikeshedding timesink :) I'll get some style-related drafts published on the weekend and then we'll see how it goes from there. Indeed, I won't mind to spearhead this (if I knew how!) since the whole documentation story is very sad, provides D with negative publicity and provides users like us with constant annoyance (but... it can be fixed -- we all know it).
dlang.org redesign -- the state of documentation and learning resources [part 2]
In continuing the series of rant posts about the website, this one will be about the documentation. This is a big one and no fixing css or pretty menus can amend this. I've recently started learning Rust myself (a few weeks ago) and despite the alpha state of both rustc and rust-lang.org website, I found it great and exciting to learn the language. There is a well-thought-out official guide that was a breeze to read through -- I've read most of it while commuting to work on my phone. Then there's Rust by Example which is essentially a semi-organized collection of how-tos, gotchas, snippets and code samples. Rust is not the easiest language of all to learn, but they try to make it simple for those who try. On the bright side, D has a book. Or rather, it has THE book and a few more books, some of which are free and some are not. However, I wouldn't ever start to read a 500-page manuscript just in order to get acquainted with the language and poke around. There needs to be an official Guide that is not too overly detailed and written in an easy language. To give a few examples: - http://doc.rust-lang.org/book/ - https://www.ruby-lang.org/en/documentation/quickstart/ - http://ocaml.org/learn/tutorials/basics.html I personally see learning and documentation as two different classes of information. Learning resources might include tutorials, code examples, articles, books, whereas documentation would be a place for more formal (and sometimes computer-generated) information on the standard library, API reference, language grammar and maybe an official style guide. Ideally, the Learning section would be sufficient for a rookie to get started and that should be the go-to destination for all newcomers. 1.1) Documentation: D Reference Is very hard to browse or search. I don't remember how many times I was looking for an is statement docs only to find again, buried under h4IsExpresssion/h4 in expression.html, a dozen of pages scrolling down from top. There are no TOCs in the files, there is no global TOC, the drop-down menu on the left is extremely long and non-nested and takes one screen vertically. All in all though, the contents are OK -- it does require some polishing, it needs to be properly indexed and laid out but that's doable without changing the contents much. 1.2) Documentaiton: Standard Library There's been some good progress on it recently by Andrei -- but it's auto-generated for the most part so the most of work is in hacking ddoc and styling. The only two issues I could point out is the landing page for Standard Library -- I would expect to see a structure of D's stdlib or a nice index and quick links rather than a why this and why that wall of text (which should stay as a separate page, but not as an entry point to the standard library pages, from the usability point of view). Another point: there needs to be a better on-site search. Apologies for mention Rust again, but: http://doc.rust-lang.org/std/index.html (type S, see what happens -- the search is not perfect but it's incremental and you can search for functions/traits separately). Since we are the ones who generate the docs, we can totally do this (in a simplest way, bake in the markers into the ddoc and generate a javascript hashmap to trace back to them). 1) D Learning This is the most problematic part. It's not even obvious where to start. Say I just landed on dlang.org via a google search and I want to find a quick user guide. I click D Reference (that seems the closest one to beginner's guide out of all options) and I see an Introduction page. Ok, looks promising, what do we have there... Ouch, Phases of Compilation, that went wrong fast. Let's try the next one, Lexical. Ouch, wall of text composed of ascii characters, unicode escapes and all other boring things. Let's go back to Books Articles. Now, Ali's book is sure very nice, but it's way overly detailed for introduction as it's trying to miss a single thing (which is sure a good thing! ... that is, if you actually decide on reading a BOOK in a first place). Plus, it's not on dlang.org so it doesn't feel official. Going back to more books, we see some 5-7 year old books, some very recent ones (but not free), and a few tutorials on a specific areas (like Philip's) -- again, nothing really qualifies as an introduction guide. This section is definitely more well-suited for intermediate D programmers who already know what they want to learn. Books Articles - Howtos (is that a book or an article?). This links to a wiki.dlang.org (yet another site?..) where we have an unorganized mess of links. Some of them sound useful but it's unlikely we are interested in voldemort types or unittest placement yet. In fact, I've just found out there's a bunch of information on wiki that I see myself for the first time -- if it took me several years, how long will it take a newcomer? It would be nice to move the
Re: dlang.org redesign -- general thoughts and issues [part 1]
On Friday, 23 January 2015 at 17:41:21 UTC, Zach the Mystic wrote: Basically, I suggest consciously addressing these four demographics in designing the site: 1. Experienced programmers, new to D. 2. Beginning programmers. 3. Experienced D users. 4. The community. Publications, social events, news chatter. Agreed. I personally think #1 is the most troublesome (although all four points will need to be addressed). E.g., Ali's book is more aimed at #2, whereas most other resources are more aimed at #3. There has to be a I know how to code, give me some D already, now! sort of a brief guide which would introduce you to the COOL parts that are different in D or that make it stand out. An experienced programmer could just jump into metaprogramming part right away because it's FUN... but that usually doesn't come until page 500 of the book... Regarding #4, I don't think anyone would support my highly subjective opinion because everyone's used to how things are, but here goes anyway: (1) mailing lists are too 90s, there exist many modern platforms that are better suitable for modern web and mobile, the current forum is actually a heroic attempt to make something usable out of a mailing list but that's that. No syntax highlighting, no editing? Come on... (2) bugzilla is too unfriendly; using github issues for review queues, milestone tracking, bug tracking, issue tracking and referencing would be easier than scattering all that across 4 different websites (that aren't updated anyway). I have found a good amount of bugs in my D experience but I'm guilty of not submitting a single one because I don't feel like making an account on bugzilla -- and I'm not planning too, it instantly repulses me as soon as I open the page; plus it's unintuitive to browse, contains outdated issues and just feels foreign in general.
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Friday, 23 January 2015 at 18:00:13 UTC, Andrei Alexandrescu wrote: On 1/23/15 9:03 AM, aldanor wrote: [NB] SUGGESTION: initiate work on an Official Guide and keep it up to date with the latest language features. That would be fantastic, and something that might be parallelizable as well. Here's a related thought: I wonder what it would take to put together a nice slideshow-style progression, with editable code snippets and stuff. Then I'd be happy to work on the content. -- Andrei What do you mean by a slideshow style progression? Would you have an example? I thought of something simple http://rustbyexample.com/ as a guideline, but hosted officially on dlang.org and being part of the website. Is that close? /* don't worry much about implementing the cool client-side UI stuff if that's what you mean, whatever it is, it's all doable (or, in all likelihood, it has already been done in a form of some js library) and it normally only takes one person to integrate it it; writing a cohesive exciting (!) user guide though is a big undertaking and responsibility. As you said though, it can be highly parallelizable! */
Re: dlang.org redesign -- general thoughts and issues [part 1]
On Friday, 23 January 2015 at 19:18:34 UTC, Chris wrote: On Friday, 23 January 2015 at 13:39:23 UTC, Christof Schardt wrote: aldanor i.s.smir...@gmail.com schrieb im Newsbeitrag news:didzczqdggjchqgtg...@forum.dlang.org... Hi all, I've started redesigning dlang.org AGAIN (yea, I Very sensible considerations. I think your way is the right way to go: first think about structure, then presentation and finally style. Yep. And please: accessibility. We wouldn't want to put off visually impaired users. JS gives them pain. Yep, that crossed my mind as well, good point. You sort of get that for free when using mature css frameworks since all elements are already ridden with things like 'role=navigation' etc :)
Re: dlang.org redesign -- general thoughts and issues [part 1]
On Friday, 23 January 2015 at 12:47:36 UTC, Jacob Carlborg wrote: Top-level-link: CHANGELOG It's updated when there's a new release. Not always -- e.g. there's several notes on 2.067 there already. I always thought that updating the changelog right after you fix something is easier than trying to recall whatever it was the hell you were working on half a year later and/or recover it from commits and pull requests, but to each his own, I guess. Plus, the changelog will have to be there anyway before the release so it's unavoidable. The question is whether it should be updated more frequently or in a more organized fashion. It's good publicity and it's nice to have a sneak peek of the next release to keep people excited, all I'm saying. On Friday, 23 January 2015 at 12:47:36 UTC, Jacob Carlborg wrote: Top-level links: STANDARD LIBRARY, D REFERENCE I think they deserve being top-level links. I'd argue that the top links should be Learn (official D newcomer's guide which is not written yet, more about it on my next post / D by example which is not written yet either / gotchas and faqs / porting c/c++ / books and articles) and Docs (which would be: standard library / language reference / official style guide). These two are intertwined and scattered all over the place on D website. Examples: http://ocaml.org/ (Learn / Documentation), http://www.rust-lang.org/ (Book / Reference), etc. This would be much more newbie-friendly. For D veterans, we could just add shortcuts to quickly jumping to stdlib or language reference.
dlang.org redesign -- a better code sample for landing page
Does anyone find the example on the landing page particularly exciting? (aside from it using an rdmd shebang) Anything that makes you, as a programmer, think -- huh, that's interesting, I'll need to check that out. It would be nice if it showcases more of D's strong parts, e.g. type inference -- so an auto declaration could be used, maybe assoc arrays or range stuff. Maybe even a little bit of templating seeing how that's an integral part of D and how much more natural meta code looks like as compared to many other languages. This is a very important snippet of code as it serves as the face of the front page of the language, I suggest we put some thought into it and make it more interesting and elegant. Any objections? Any takers? Another option is to have multiple code samples and rotate them -- that's what Ruby does.
Re: dlang.org redesign -- a better code sample for landing page
On Friday, 23 January 2015 at 13:34:36 UTC, aldanor wrote: Does anyone find the example on the landing page particularly exciting? (aside from it using an rdmd shebang) Anything that makes you, as a programmer, think -- huh, that's interesting, I'll need to check that out. It would be nice if it showcases more of D's strong parts, e.g. type inference -- so an auto declaration could be used, maybe assoc arrays or range stuff. Maybe even a little bit of templating seeing how that's an integral part of D and how much more natural meta code looks like as compared to many other languages. This is a very important snippet of code as it serves as the face of the front page of the language, I suggest we put some thought into it and make it more interesting and elegant. Any objections? Any takers? Another option is to have multiple code samples and rotate them -- that's what Ruby does. In fact, the current example (which is not the greatest of all) is essentially a one/two-liner, something along the lines of: auto lines = stdin.byLine.map!(line = line.length); writefln(Average line length: %.4f., 1.0 * lines.sum / lines.array.length); Ofc this is not the greatest piece of code ever and it's not lazy, but at the very least it showcases an auto declaration, a lambda, a formatted print, a template invocation and UFCS syntax, you get the point... oh wait, that and a lack of a mean function in the standard library... I bet you will come up with much better ideas!
dlang.org redesign -- general thoughts and issues [part 1]
Hi all, I've started redesigning dlang.org AGAIN (yea, I know...). The front page is mostly done aside from a several responsiveness and platform quirks, I will have the full landing page + a random sample page from the docs this weekend. On the technical side, rapid design + ddoc and working with pure css don't work well together, so it's going to be a static page or two and if/when everyone/anyone's happy with it, it can be pulled apart into those fugly ddoc macros. An easy example of why that's the case would be changing the color scheme or general styling of multiple components -- in sass/less you can just do a @active-component: darken(@martian-red, 5%); and that will fix all the inherited ones across the stylesheet. Same applies to reorganizing content in drastic ways. If using node as a dependency to compile assets is acceptable, this would sure the preferred way; otherwise, the compiled assets could be frozen/minified and checked back in. More about design-specific stuff later in another post. There are several issues with structure and presentation that I think will have to be addressed. While compiling these, I also had several people that know nothing about D look at the website structrure and make independent comments. Please see my semi-organized collection of thoughts below. Top-level link: APPENDICES ... what is that even supposed to mean? It looks more of an official D style guide. TODO: rename to D STYLE GUIDE. TODO: someone needs to go through it and update it to look more official-style-guide-ish. And then again, it may be moved into a learning/docs section and not be a top-level item. Top-level link: FAQ ... looks like a collection of stuff that doesn't belong anywhere. The FAQ is almost as bad as naming it MISC. Some of the points actually look like they belong to an FAQ (why D?), other ones belong to an official guide or examples; I wouldn't ever guess that the info on anonymous structs/unions would be in FAQ, that's just wrong. (there's also Books Articles -- How-tos etc; which makes it even harder). Top-level link: D1 HOME ... should be buried away somewhere deep as not to scare people away. Those who need to find it already know where it is. Top-level-link: CHANGELOG ... is stale and rarely / randomly updated. This makes it look like there is no development on the backend/phobos/runtime going on whatsoever. There either needs to be an automated aggregator for github pull requests (in which case there will need to be a better policy on commit/pr descriptions so it's automatable), or a responsibility of whoever's merging it to spend 5 seconds of time to update the changelog (e.g. nasty ice bug fixed, bugzilla issue #123, github pr #456). There should also be a friendly way to quickly see a list of releases with dates and summaries and navigate to release notes for each one without scrolling through 42km of text. Top-level link: SITEMAP ... should be removed, it's not 1999 anymore. Plus, a well-structured website never needs a sitemap. Top-level-link: VISUAL D ... should move under Downloads Tools; having this at top-level has a Windows smell and may scare people away. Top-level links: STANDARD LIBRARY, D REFERENCE ... I suggest they are moved back into Documentation section (as it is on the forum.dlang.org) which will contain these (Language Reference / Standard Library) plus other subsections e.g. D Style Guide. Book-Tutorial link (on forum.dlang.org) and other external links: This is one of many random external links: http://www.informit.com/articles/article.aspx?p=1381876. It's just a really bad style for an official language website to link to an article obscure external website (that is 5 years old and probably outdated anyway). I suggest this is removed; and, in case any of the information in that tutorial is not duplicated in other guides, be manually moved/copied somewhere else (or be made a part of the official guide/tutorial). REVIEW QUEUE: ... has this even changed at all in 6 months? If not, remove it from top-level. This gives an impression of stagnation if anyone were to follow that link and click History (I did).
Re: forcing @nogc on class destructors
On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim Grøstad wrote: How about banning GC-allocation of classes with destructors? Uh... what? ^__^ Maybe just ban classes altogether then?
Re: forcing @nogc on class destructors
On Friday, 23 January 2015 at 13:12:44 UTC, Steven Schveighoffer wrote: On 1/23/15 8:05 AM, Matthias Bentrup wrote: On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote: On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim Grøstad wrote: How about banning GC-allocation of classes with destructors? Uh... what? ^__^ Maybe just ban classes altogether then? No, don't ban them, that will break to much code. Just don't execute them. Any application that depends on destructors being called by the GC is broken in 9 out of 10 cases anyway. This is very wrong. -Steve Summing up the arguments in this thread, I think the reasonable middle ground here would be for a compiler to throw a warning if dtor doesn't satisfy @nogc. I.e., compiler knows at compile time that something MAY and probably WILL go wrong; the code as of current GC implementation is then unsafe which should be reported to the user. This is much better than just silent obscure memory exceptions at runtime.
Re: Show AAs in all their virtues
On Friday, 23 January 2015 at 16:25:56 UTC, Per Nordlöw wrote:
I believe we should show off D in all its virtue
at http://dlang.org/hash-map.html
by addition to
int* p = (hello in aa);
if (p !is null) {}
also include the even compacter
if (auto p = hello in aa) {}
along with
if (const p = hello in aa) {}
in the non-mutating case.
Destroy!
Is this in regards to
http://forum.dlang.org/thread/nddqjyjeqihajlhds...@forum.dlang.org?
If so, would you cc your reply in that thread? Thanks.
Re: dlang.org redesign -- general thoughts and issues [part 1]
On Friday, 23 January 2015 at 12:32:00 UTC, Jacob Carlborg wrote: For Sass there's libsass [1] with bindings already available [2]. For running JavaScript (Less) there are a couple of alternatives: Thanks, that would help. Could either use bootstrap-sass from git + d bindings to libsass from dub, or alternatively less via dmdscript -- but the first one would be easier, I guess.
Re: dlang.org redesign n+1
On Thursday, 22 January 2015 at 17:15:59 UTC, MattCoder wrote: On Thursday, 22 January 2015 at 17:03:52 UTC, Meta wrote: On Thursday, 22 January 2015 at 17:00:55 UTC, MattCoder wrote: On Thursday, 22 January 2015 at 16:58:39 UTC, Meta wrote: On Thursday, 22 January 2015 at 05:27:04 UTC, Zekereth wrote: First of all I like the new design. Way better than what's here now. I'll just throw another site into the mix that I like which is Ocaml's site: https://ocaml.org/ . That's quite nice. It even has a section with recent forum posts. Maybe we should try to emulate it. We are already doing that: http://dlang.org/ - Look at your right :) Matheus. It doesn't show up on my phone. Oh yes, In mine It doesn't show up only when Vertical, but I can see in Horizontal. Anyway, I more meant that we should model our general design off of ocaml.org as their site looks pretty good but still has a lot of information. Indeed, that https://ocaml.org/ is a good start. Matheus. OCaml's site's using Bootstrap as a framework.. surprise surprise :)
Re: dlang.org redesign n+1
On Wednesday, 21 January 2015 at 17:10:09 UTC, Sebastiaan Koppe wrote: On Wednesday, 21 January 2015 at 16:30:37 UTC, Andrei Alexandrescu wrote: This is awesome, and something I'd get behind. Here's a little feedback coming from a self-admitted dilettante: * On my laptop it looks like this: http://imgur.com/v8TC1xq. I'm seeing the red menu at the top, the gray sparse box, and also an odd fragment of the next page which has a different background, a title, and a fragment of code snippet. The way I look at it is either you go balls-out with the sparse gray page and make it occupy the entire viewport, or you make it smaller to allow me to get to some content. As things are I can't stop wondering: Why did they waste all that space so I can't see stuff? (...) * Generally I feel I must scroll too much through too little (and occasionally crappy - not your fault) content on the homepage. There's just so much air. But that might be part of the page's very look and feel, so if people like it no problem. Agreed. Again, it is a proof-of-concept. * Page doesn't seem to load on mobile at all. Hmm, that is odd. Some other people said the same thing. Loads fine on mine though... * Clicking on Overview while I'm on the homepage does nothing. But there's no visual indication I'm already on Overview. Also clicking on Overview or the logo seem to do the same thing. Oh, wait, not all menus are meant to work - take that back. There are no navigational helpers indeed. Didn't know how to get the current page from within ddoc to set css stuff to highlight things etc. * There's no accordion on Language Reference which makes for a really tall menu, sometimes even longer than the content itself. I find that hard to navigate. Statistically nobody will get to Visual D and Community :o). Haha. There are some other pages as well that nobody gets to read in full. * Layout is jerky as I reduce the width of the page: sometimes the right/left margins are really wide, even on thin viewports, thus wasting already precious space, then they get thin, then they get wide again, etc. There is a mismatch between some responsive stuff. Saw it as well. It's just about playing with thresholds, and alot of tweaking. You should have no trouble building dlang.org on linux following the instructions at https://github.com/D-Programming-Language/dlang.org/blob/master/CONTRIBUTING.md. Will look into it. The rationale for NOT using /usr/bin/dmd etc. is that oftentimes the docs use specific features of the compiler, which means you need to build a specific library docs with the same compiler version. For the site proper we always use the development version of dmd (which by default we assume is ../dmd/src/dmd) so people can change the compiler and the docs in tandem. Once you get that in place things should work smoothly. Yeah, but where can I get /dmd/src/dmd? Do I need to fork the dmd source code? Sebastian, could please you publish your fork somewhere so we could take a closer look and/or fork/destroy it? It would also be easier to make specific suggestions
Re: dlang.org redesign n+1
On Wednesday, 21 January 2015 at 15:35:59 UTC, Chris wrote: On Wednesday, 21 January 2015 at 14:46:22 UTC, Sebastiaan Koppe wrote: Just for fun and proof-of-concept I went ahead and forked the dlang.org site. I basically took the `do-what-everybody-else-is-doing` approach: http://dlang.skoppe.eu It is still a wip, but the landing page and the language reference (see Docs menu-item) is working. Doing the ddoc was a maze of macro's at first. But spending a couple of hours untangling the mess, I finally found the ones I needed to change. After that things went pretty smooth. So ddoc ain't that bad. It is just that I didn't have syntax highlighting - nor goto-definition - and I hate that. Still, it is cool in a way that I can just change some macro's, tweak the index.dd, the doc.ddoc and don't have to worry about all the other pages. BTW, the build process on windows was way easier than linux. In fact, I could not get the makefile to run on linux at all. Looking into posix.mak, I see a blur of path's, all misconfigured, and I bet I am supposed to set those manually. I don't get it, doesn't everything has its own place? Isn't dmd always installed in /usr/bin, /usr/include/dmd and that stuff? I suppose not everyone is using the same distro. Or they are, except me :) Good start. A few points: 1. The font is too big (see also 2.). 2. A lot of space is wasted. To fix this, maybe it would help to lay it out in tiles (two or three items in one row, cf http://foundation.zurb.com/). As it is now, the three major points Convenience, Power and Efficiency are too far apart, there's too much scrolling involved (which users hate). All the important information should be visible at once. 3. No need to use so much space for The D Programming Language, especially since we don't have a fancy graphic to fill that space (why should we). 4. Tools like DUB etc. should be bundled as on the Foundation homepage under something like Build products, apps and services Good work in the right direction!.. and now for some bikeshedding: Agreed with Chris on (1), (2), (3), plus: (4) Not mobile-ready / not responsive. Try resizing horizontally and see what happens. This is related to (2) and could be solved by using a proper grid framework. (5) Use a better sans serif font (with a fallback to browser default sans family), it actually matters a lot :) Like Fira Sans, Helvetica Neue or something like that. Could use a better monospaced font as well (6) Hover-on/-off effects (like in the menu above) are usually frowned upon since they won't work on mobile devices as you expect. It's sometimes better to just have plain properly styled links. (7) The search bar seems misplaced
Re: dlang.org redesign n+1
On Wednesday, 21 January 2015 at 17:16:52 UTC, Sebastiaan Koppe wrote: On Wednesday, 21 January 2015 at 17:12:22 UTC, aldanor wrote: Sebastian, could please you publish your fork somewhere so we could take a closer look and/or fork/destroy it? It would also be easier to make specific suggestions https://github.com/skoppe/dlang.org I case you only want to make changes to the css, you can checkout the `compiled` branch and just make changes to the css/styles.css Great stuff, thanks a mil. I'll try to poke around tonight and see how to address some of the issues mentioned here
Re: dlang.org redesign n+1
On Wednesday, 21 January 2015 at 23:25:04 UTC, Mike wrote: On Wednesday, 21 January 2015 at 19:51:57 UTC, Walter Bright wrote: The Dart one is probably most similar to this proposal. But there definitely is a trend among these sites - a menu across the top, lots of white space, lots of scrolling. I can't say I'm a fan, but it's undeniable what people consider modern. (I like the older style, as it is denser and easier to navigate.) You forgot Nim: http://nim-lang.org And I personally like Nim's website best. I have to agree with Walter, and prefer the denser design. This proposal is attractive, though, but the new website trends are too sparse. I realize this is the modern trend, but that trend seems to treat eveything like a 5 smartphone. Mike Nim site is not responsive and looks stupid on a mobile device.
Re: forcing @nogc on class destructors
On Tuesday, 20 January 2015 at 21:30:14 UTC, Steven Schveighoffer wrote: On 1/20/15 4:06 PM, ketmar via Digitalmars-d wrote: On Tue, 20 Jan 2015 15:51:17 -0500 Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com wrote: p.s. another point is that all mechanics compiler needs for doing such checks is already there, so it's not a huge change to compiler codebase. it's not something that requires adding a whole new analysis code. You can always put @nogc on the dtor if you want. -Steve I got into habit of always doing that (after painfully learning on my own mistakes...) -- I guess the question of the thread is -- is there a SINGLE reason to not force this at the moment?
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 10:16:15 UTC, Jacob Carlborg wrote: On 2015-01-18 03:18, Andrei Alexandrescu wrote: I took the better part of today working on this: https://github.com/D-Programming-Language/dlang.org/pull/780. See demo at http://erdani.com/d/. What do you all think? Is it an improvement over what we have now? It looks absolutely horrible. It was way, way better before On iPhone 6: D, Rust, Python, Ruby websites (Ruby being particularly gorgeous and D looking particularly ancient and out of place): http://imgur.com/7Vb2ynM http://imgur.com/SGKUd2q http://imgur.com/bXk1lf9 http://imgur.com/njSgbzW
Re: Use proper frameworks for building dlang.org
On Sunday, 18 January 2015 at 13:01:48 UTC, MattCoder wrote: On Sunday, 18 January 2015 at 10:24:29 UTC, Jacob Carlborg wrote: What do you think? I'm seeing a lot a topics regards about fixing website, styles an so on. Maybe is time to try to raise money and hire someone with good knowledge and of course freetime to work only on it? Matheus. It also looks a bit wrong seeing Andrei as one of the core devs putting so much time into the website issues, styling in particular (don't get me wrong, this is absolutely fantastic that someone's willing to do that, thanks Andrei -- and it looks like most of the community now recognizes the need). It's that any semi-decent web designer would probably do a better job on the website design and layout while still spending less time doing that (because they've done it a hundred times already and/or do it for living). However, not every web designer can hack on system language internals and review D PRs!.. So someone needs to step up and do it (and/or redo it, and/or hire someone to do it). That's just my 2 cents which is purely subjective.
Re: Use proper frameworks for building dlang.org
On Sunday, 18 January 2015 at 10:24:29 UTC, Jacob Carlborg wrote: Lately Andrei has worked a lot with improving the dlang.org site in various ways. To me it getting more clear and clear that Ddoc is not the right tool for building a web site. Especially the latest improvement [1] shows that it's not a good idea to reinvent the wheel, especially when it's not an improvement, at all. Why don't we instead make use of a proper framework both on the server side and client side. Personally I would go with Ruby on Rails but I know that most of you here would hate that so a better suggestion would probably be vibe.d. For the client side I'm thinking Bootstrap and jQuery. The biggest reason why I would prefer Rails is because I know everything that is needed is already implemented and easily available. I can not say the same thing about vibe.d. But it might be enough for dlang.org, I don't know. What do you think? [1] http://forum.dlang.org/thread/m9f558$lbb$1...@digitalmars.com I would agree on this in general. Not sure about Rails (because it is totally an overkill and may be a pain to maintain) but everyone has their own preferences for the backend and templating engine in this case even a proper static generator (Jekyll if you're talking Ruby) with a proper responsive front end (JQuery + Bootstrap / Foundation / Semantic UI / whichever) would do. If it's markdown-based, it would also significantly lower the barrier for people other than a few devs who would like to contribute to the docs and website but would hate to do it in ddoc.
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 17:05:28 UTC, Andrei Alexandrescu wrote: On 1/18/15 9:02 AM, aldanor wrote: This is usually solved by media queries / responsive design / grid frameworks, sorry if I'm stating the obvious :) Try resizing the commonly used websites and see what happens, e.g. for ruby-lang you have at least 3 versions which are selected automatically based on the current viewport's settings which the browser provides: http://imgur.com/a/gE38d E.g. the menus on the left getting folded into one mobile button which expands them on demand and leaves more space for the actual content, or some elements disappearing in smaller viewports altogether (like the twitter feed div). This is quite a pain to manage manually without having an underlying grid framework. My understanding is there are various simpler way to do this, e.g. separate styles for small screen devices, redirection to a different URL, setting hidden to certain DIVs dynamically etc. etc. As you saying there's no way to do this unless we use some grid framework I know nothing about and probably need to learn? -- Andrei The thing with frameworks is that some designers have put a considerable amount of time on putting them together, making them cross-browser compatible, working around various edge cases etc (and there are many...) -- so that you won't have to. Once you want something like responsiveness + automatic reflows, things start getting even more complicated... Not all frameworks are gigantic like bootstrap/foundation, there's some smaller ones that just do the grid thing (like 960). (that, or you can always pull just the bits you want from bootstrap or anything and minify it). Another point is that if you use the elements the framework provides (e.g. navbar menu), they would be already nicely compatible with the framework's grid system. As an example -- try resizing the width here and see what happens: http://getbootstrap.com/examples/grid/. There's also some minimalistic frameworks -- like PureCSS, just to give an example -- http://purecss.io and https://github.com/yahoo/pure, where the entire grid system is just 0.8KB.
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 17:05:28 UTC, Andrei Alexandrescu wrote: On 1/18/15 9:02 AM, aldanor wrote: This is usually solved by media queries / responsive design / grid frameworks, sorry if I'm stating the obvious :) Try resizing the commonly used websites and see what happens, e.g. for ruby-lang you have at least 3 versions which are selected automatically based on the current viewport's settings which the browser provides: http://imgur.com/a/gE38d E.g. the menus on the left getting folded into one mobile button which expands them on demand and leaves more space for the actual content, or some elements disappearing in smaller viewports altogether (like the twitter feed div). This is quite a pain to manage manually without having an underlying grid framework. My understanding is there are various simpler way to do this, e.g. separate styles for small screen devices, redirection to a different URL, setting hidden to certain DIVs dynamically etc. etc. As you saying there's no way to do this unless we use some grid framework I know nothing about and probably need to learn? -- Andrei And yet another thing you gain with (most) frameworks is having access to the original SASS/LESS. This essentially provides you with features like inheritance, mixins and default values for CSS which reduces the boilerplate and makes the whole thing much more manageable.
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 16:23:35 UTC, Andrei Alexandrescu wrote: On 1/18/15 2:36 AM, ponce wrote: On Sunday, 18 January 2015 at 10:27:43 UTC, aldanor wrote: On Sunday, 18 January 2015 at 10:16:15 UTC, Jacob Carlborg wrote: On 2015-01-18 03:18, Andrei Alexandrescu wrote: I took the better part of today working on this: https://github.com/D-Programming-Language/dlang.org/pull/780. See demo at http://erdani.com/d/. What do you all think? Is it an improvement over what we have now? It looks absolutely horrible. It was way, way better before On iPhone 6: D, Rust, Python, Ruby websites (Ruby being particularly gorgeous and D looking particularly ancient and out of place): http://imgur.com/7Vb2ynM http://imgur.com/SGKUd2q http://imgur.com/bXk1lf9 http://imgur.com/njSgbzW Looks like tweets occupy valuable screen estate on this device. Can we ditch the twitter div on mobile? (Pull request would be nice, thanks.) -- Andrei This is usually solved by media queries / responsive design / grid frameworks, sorry if I'm stating the obvious :) Try resizing the commonly used websites and see what happens, e.g. for ruby-lang you have at least 3 versions which are selected automatically based on the current viewport's settings which the browser provides: http://imgur.com/a/gE38d E.g. the menus on the left getting folded into one mobile button which expands them on demand and leaves more space for the actual content, or some elements disappearing in smaller viewports altogether (like the twitter feed div). This is quite a pain to manage manually without having an underlying grid framework.
Re: 10 Tips for Better Pull Requests
On Saturday, 17 January 2015 at 11:52:03 UTC, Jacob Carlborg wrote: On 2015-01-16 19:50, deadalnix wrote: It is better to have some kind of bot that comment on the PR after a while. Like hey, this PR is hanging, can someone make thing go forward or I'll close in 2 more month. That generate activity on the PR and is often a wake up call for people. Ruby on Rails has something like that for their project. Although there's a huge unfairness if a reviewer never replies. Just because a reviewer doesn't reply doesn't mean the problem (i.e. a bug) goes away. Yes, they're using this for issues. The whole thing would be much easier if github issues were used instead of bugzilla -- for one thing, it would automatically mention it in a pull request (or an issue) if it was mentioned anywhere in another issue / pull request which makes browsing and figuring what relates to what much easier (instead of having to search bugzilla / forum / pull requests here and having three different places to register things at). Just my 2 cents...
Re: Please help me with improving dlang.org
On Sunday, 18 January 2015 at 02:18:16 UTC, Andrei Alexandrescu wrote: I took the better part of today working on this: https://github.com/D-Programming-Language/dlang.org/pull/780. See demo at http://erdani.com/d/. What do you all think? Is it an improvement over what we have now? I'd appreciate your help with reviewing and pulling this, and also with improving the colors (which I'm terrible at) and page tracking as mentioned in the pull request. Thanks, Andrei The layout looks pretty bad on a mobile device you kind of expect it to be properly responsive these days. That might be one thing to get fixed.
Re: 10 Tips for Better Pull Requests
On Friday, 16 January 2015 at 18:50:29 UTC, deadalnix wrote: On Friday, 16 January 2015 at 16:22:13 UTC, ketmar via Digitalmars-d wrote: it sits in queue without any comments more than 20 days? reject and close it. It is better to have some kind of bot that comment on the PR after a while. Like hey, this PR is hanging, can someone make thing go forward or I'll close in 2 more month. That generate activity on the PR and is often a wake up call for people. On a relevant sidenote: this is a GitHub buildbot that manages Rust's main repo, PR approvals and all that: https://github.com/graydon/bors IMO that seems to work quite well for Rust and lowers the administrative burden on reviewers.
Re: [unittest] constness
On Saturday, 17 January 2015 at 00:38:09 UTC, Luc Bourhis wrote: Testing constness implementation is easy: const Foo a; a.non_const_method(); // compilation fails but how would I catch that in a unittest? Something like this? static assert(!__traits(compiles, a.non_const_method()))
Re: This Week in D, issue 1
On Thursday, 15 January 2015 at 09:46:52 UTC, Szymon Gatner wrote: On Tuesday, 13 January 2015 at 14:08:58 UTC, Adam D. Ruppe wrote: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! http://arsdnet.net/this-week-in-d/jan-12.html In the future, I intend to have it written by Saturday for a weekend release, so if you want something to appear this week, please try to get it to by before then. Fantastic inititive Adam, thanks for donating your time for this. An issue I have tho: // classes are reference types, so they must be // initialized. MyClass c;, unlike in C++, would // leave c as null, causing a segfault when you try // to use it. That is not really true, is it? In C++ MyClass c; is actually THE way to instantiate objects. I know you meant MyClass* but as it is now it is just plain incorrect. Eh.. what exactly is incorrect? In C++ MyClass c; stack-allocates the class assuming the default constructor is there (unless of course this is a member declaration in an object that's static or heap-allocated). In D it doesn't, it leaves you with an unitialized reference type.
Re: D Beginner Trying Manual Memory Management
On Wednesday, 14 January 2015 at 14:54:09 UTC, Laeeth Isharc
wrote:
In the hierarchy example above (c++ hdf hierarchy link), by
using UFCS to implement the shared methods (which are achieved
by multiple inheritance in the c++ counterpart) did you mean
something like this?
// id.d
struct ID { int id; ... }
// location.d
struct Location { ID _id; alias _id this; ... }
// file.d
public import commonfg; // ugh
struct File { Location _location; alias _location this; ... }
// group.d
public import commonfg;
struct File { Location _location; alias _location this; ... }
// commonfg.d { ... }
enum isContainer(T) = is(T: File) || is(T : Group);
auto method1(T)(T obj, args) if (isContainer!T) { ... }
auto method2(T)(T obj, args) if (isContainer!T) { ... }
I guess two of my gripes with UFCS is (a) you really have to
// another hdf-specific thing here but a good example in
general is that some functions return you an id for an object
which is one of the location subtypes (e.g. it could be a File
or could be a Group depending on run-time conditions), so it
kind of feels natural to use polymorphism and classes for
that, but what would you do with the struct approach? The only
thing that comes to mind is Variant, but it's quite meh to use
in practice.
Void unlink(File f){}
Void unlink(Group g){}
For simple cases maybe one can keep it simple, and despite the
Byzantine interface what one is trying to do when using HDF5 is
not intrinsically so complex.
So your solution is copying and pasting the code?
But now repeat that for 200 other functions and a dozen more
types that can be polymorphic in weirdest ways possible...
Re: D Beginner Trying Manual Memory Management
On Wednesday, 14 January 2015 at 16:27:17 UTC, Laeeth Isharc
wrote:
struct File { Location _location; alias _location this; ... }
// group.d
public import commonfg;
struct File { Location _location; alias _location this; ... }
// commonfg.d { ... }
enum isContainer(T) = is(T: File) || is(T : Group);
auto method1(T)(T obj, args) if (isContainer!T) { ... }
auto method2(T)(T obj, args) if (isContainer!T) { ... }
I guess two of my gripes with UFCS is (a) you really have to
// another hdf-specific thing here but a good example in
general is that some functions return you an id for an
object which is one of the location subtypes (e.g. it could
be a File or could be a Group depending on run-time
conditions), so it kind of feels natural to use polymorphism
and classes for that, but what would you do with the struct
approach? The only thing that comes to mind is Variant, but
it's quite meh to use in practice.
Void unlink(File f){}
Void unlink(Group g){}
For simple cases maybe one can keep it simple, and despite
the Byzantine interface what one is trying to do when using
HDF5 is not intrinsically so complex.
So your solution is copying and pasting the code?
But now repeat that for 200 other functions and a dozen more
types that can be polymorphic in weirdest ways possible...
If you are simply have a few lines calling the API and the
validation is different enough for file and group (I haven't
written unlink yet) then why not (and move proper shared code
out into helper functions). The alternative is a long method
with lots of conditions, which may be the best in some cases
but may be harder to follow.
I do like the h5py and pytables approaches. One doesn't need
to bother too much with the implementation when using their
library.
However, what I am doing is quite simple from a data
perspective - a decent amount of it, but it is not an
interesting problem from a theoretical perspective - just
execution. Now if you are higher octane as a user you may be
able to see what I cannot. But on the other hand, the Pareto
principle applies, and in my view a library should make it
simple to do simple things. One can't get there if the primary
interface is a direct mapping of the HDF5 hierarchy, and I also
think that is unnecessary with D.
But I very much appreciate your work as the final result is
better for everyone that way, and you are evidently a much
longer running user of D than me. I never used C++ as it just
seemed too ugly! and I suspect the difference in backgrounds is
shaping perspectives.
What do you think the trickiest parts are with HDF5? (You
mention weird polymorphism).
Laeeth
I don't think you've read h5py source in enough detail :) It's
based HEAVILY on duck typing. In addition, it has way MORE
classes than the C++ hierarchy does. E.g., the high-level File
object actually has these parents: File : Group, Group :
HLObject, MutableMappingWithLock, HLObject : CommonStateObject
and internally the File also keeps a reference to file id which
is an instance of FileID which inherits from GroupID which
inherits from ObjectID, do I need to continue? :) PyTables, on
the contrary is quite badly written (although it works quite well
and there are brilliant folks on the dev team like francesc
alted) and looks like a dump of C code interweaved with hackish
Python code.
In h5py you can do things like file[/dataset].write(...) --
this just wouldn't work as is in a strictly typed language since
the indexing operator generally returns you something of a
Location type (or an interface, rather) which can be a
group/datatype/dataset which is only known at runtime. Out of all
of them, only the dataset supports the write method but you don't
know it's going to be a dataset. See the problem? I don't want
the user code to deal with any of the HDF5 C API and/or have a
bunch of if conditions or explicit casts which is outright ugly.
Ideally, it would work kind of like H5PY, abstracting the user
away from refcounting, error code checking after each operation,
object type checking and all that stuff.
Re: A naive attempt at a refcounted class proxy
On Tuesday, 13 January 2015 at 16:43:09 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 13 Jan 2015 16:17:51 +
aldanor via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
This discussion:
http://forum.dlang.org/thread/bqtcdpsopxmnfbjyr...@forum.dlang.org
-- led me wondering if it would be possible to create some
crippled version of a class proxy that is based on RefCounted
and came up with something like this:
struct Box(T) if (is(T == class)) {
@disable this();
this(Args...)(Args args) {
_payload._refCounted.initialize(new T(args));
}
private {
struct _Box(T) {
private T _instance;
~this() {
destroy(_instance);
}
}
RefCounted!(_Box!T) _payload;
}
~this() {
}
auto opDispatch(string name, Args...)(Args args) {
return
mixin(_payload._instance.%s(args).format(name));
}
}
which lets you create Box!SomeClass(args) and it will be
refcounted unless you escape references and do other weird
stuff.
It actually sort of seems to work at first glance, at least it
seems like it does... But with my D experience being fairly
limited I wonder what the potential pitfalls would be?
Full source code with example and stdout:
https://gist.github.com/aldanor/d5fb5e45ddf3dd2cb642
it's not that hard to make a boxed class. what is really hard
is to
make functions that expects the class itself to accept it's
boxed
variant too and behave correctly with it.
either you have to unbox it (and then hope that it will not
leak), or
write two set of functions, for real class and for boxed one.
and
then you may want to inherit from your class and pass that
inherited
class to one of the functions... and now you have three sets.
and so
on...
as structs can't be inherited, there is no such problem for
structs.
That's completely valid. Where it would work though, I think, is
if all classes are private/package and only expect/return boxed
classes and never the references. This way you sort of get
multiple inheritance (for the internal implementation) without
polymorphism, but with value semantics and ref counting for the
outward interface.
Re: A naive attempt at a refcounted class proxy
On Tuesday, 13 January 2015 at 18:12:45 UTC, aldanor wrote:
On Tuesday, 13 January 2015 at 16:43:09 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 13 Jan 2015 16:17:51 +
aldanor via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
This discussion:
http://forum.dlang.org/thread/bqtcdpsopxmnfbjyr...@forum.dlang.org
-- led me wondering if it would be possible to create some
crippled version of a class proxy that is based on RefCounted
and came up with something like this:
struct Box(T) if (is(T == class)) {
@disable this();
this(Args...)(Args args) {
_payload._refCounted.initialize(new T(args));
}
private {
struct _Box(T) {
private T _instance;
~this() {
destroy(_instance);
}
}
RefCounted!(_Box!T) _payload;
}
~this() {
}
auto opDispatch(string name, Args...)(Args args) {
return
mixin(_payload._instance.%s(args).format(name));
}
}
which lets you create Box!SomeClass(args) and it will be
refcounted unless you escape references and do other weird
stuff.
It actually sort of seems to work at first glance, at least
it seems like it does... But with my D experience being
fairly limited I wonder what the potential pitfalls would be?
Full source code with example and stdout:
https://gist.github.com/aldanor/d5fb5e45ddf3dd2cb642
it's not that hard to make a boxed class. what is really hard
is to
make functions that expects the class itself to accept it's
boxed
variant too and behave correctly with it.
either you have to unbox it (and then hope that it will not
leak), or
write two set of functions, for real class and for boxed
one. and
then you may want to inherit from your class and pass that
inherited
class to one of the functions... and now you have three sets.
and so
on...
as structs can't be inherited, there is no such problem for
structs.
That's completely valid. Where it would work though, I think,
is if all classes are private/package and only expect/return
boxed classes and never the references. This way you sort of
get multiple inheritance (for the internal implementation)
without polymorphism, but with value semantics and ref counting
for the outward interface.
// thanks ketmar for answering another one of my stupid questions
on n.g. :)
Re: D Beginner Trying Manual Memory Management
On Tuesday, 13 January 2015 at 17:08:38 UTC, Laeeth Isharc wrote:
I see, thanks! :) I've started liking structs more and
more recently as well and been pondering on how to convert
a class-based code that looks like this (only the base
class has any data):
it's hard to tell by brief description. but having multiple
inheritance
immediately rings an alarm ring for me. something is
very-very-very
wrong if you need to have a winged whale. ;-)
A real-world example:
http://www.hdfgroup.org/HDF5/doc/cpplus_RM/hierarchy.html
H5::File is both an H5::Location and H5::CommonFG (but not an
H5::Object)
H5::Group is both an H5::Object (subclass of H5::Location)
and H5::CommonFG
H5::Dataset is an H5::Object
i see something named CommonFG here, which seems to good
thing to
move out of hierarchy altogether.
bwah, i don't even sure that given hierarchy is good for D.
C++ has no
UFCS, and it's incredibly hard to check if some entity has some
methods/properties in C++, so they have no other choice than
to work
around that limitations. it may be worthful to redesign the
whole thing
for D, exploiting D shiny UFCS and metaprogramming features.
and,
maybe, moving some things to interfaces too.
I just finished reading aldanor's blog, so I know he is
slightly allergic to naked functions and prefers classes ;)
With Ketmar, I very much agree (predominantly as a user of HDF5
and less so as an inexperienced D programmr writing a wrapper
for it). It's a pain to figure out just how to do simple
things until you know the H5 library. You have to create an
object for file permissions before you even get started, then
similarly for the data series (datasets) within, another for
the dimensions of the array, etc etc - that doesn't fit with
the intrinsic nature of the domain.
There is a more general question of bindings/wrappers -
preserve the original structure and naming so existing code can
be ported, or write a wrapper that makes it easy for the user
to accomplish his objectives. It seems like for the bindings
preserving the library structure is fine, but for the wrapper
one might as well make things easy.
Eg here https://gist.github.com/Laeeth/9637233db41a11a9d1f4
line 146. (sorry for duplication and messiness of code, which
I don't claim to be perfectly written - I wanted to try
something quickly and have not yet tidied up).
So rather than navigate the Byzantine hierarchy, one can just
do something like this (which will take a struct of PriceBar -
date,open,high,low,close - and put it in your desired dataset
and file, appending or overwriting as you prefer).
dumpDataSpaceVector!PriceBar(file,ticker,array(priceBars[ticker]),DumpMode.truncate);
which is closer to h5py in Python. (It uses reflection to
figure out the contents of a non-nested struct, but won't yet
cope with arrays and nested structs inside). And of course a
full wrapper might be a bit more complicated, but I truly think
one can do better than mapping the HDF5 hierarchy one for one.
Laeeth.
In the hierarchy example above (c++ hdf hierarchy link), by using
UFCS to implement the shared methods (which are achieved by
multiple inheritance in the c++ counterpart) did you mean
something like this?
// id.d
struct ID { int id; ... }
// location.d
struct Location { ID _id; alias _id this; ... }
// file.d
public import commonfg; // ugh
struct File { Location _location; alias _location this; ... }
// group.d
public import commonfg;
struct File { Location _location; alias _location this; ... }
// commonfg.d { ... }
enum isContainer(T) = is(T: File) || is(T : Group);
auto method1(T)(T obj, args) if (isContainer!T) { ... }
auto method2(T)(T obj, args) if (isContainer!T) { ... }
I guess two of my gripes with UFCS is (a) you really have to use
public imports in the modules where the target types are defined
so you bring all the symbols in whether you want it or not (b)
you lose access to private members because it's not the same
module anymore (correct me if I'm wrong?). Plus, you need to
decorate every single free function with a template constraint.
// another hdf-specific thing here but a good example in general
is that some functions return you an id for an object which is
one of the location subtypes (e.g. it could be a File or could be
a Group depending on run-time conditions), so it kind of feels
natural to use polymorphism and classes for that, but what would
you do with the struct approach? The only thing that comes to
mind is Variant, but it's quite meh to use in practice.
Re: A naive attempt at a refcounted class proxy
On Tuesday, 13 January 2015 at 18:19:42 UTC, ketmar via Digitalmars-d-learn wrote: and then you can go with structures in the first place, i think. remember that you have that k00l `alias this` trick for them! Which doesn't always help in case of multiple inheritance :( e.g. the blasted hdf c++ class hierarchy example.
Re: This Week in D, issue 1
On Tuesday, 13 January 2015 at 14:08:58 UTC, Adam D. Ruppe wrote: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! http://arsdnet.net/this-week-in-d/jan-12.html In the future, I intend to have it written by Saturday for a weekend release, so if you want something to appear this week, please try to get it to by before then. Great stuff :) Are you planning to make the content open-source so others could suggest edits more easily? Will there be an archive?
Re: This Week in D, issue 1
On Tuesday, 13 January 2015 at 15:04:32 UTC, Adam D. Ruppe wrote: On Tuesday, 13 January 2015 at 14:28:56 UTC, aldanor wrote: Are you planning to make the content open-source so others could suggest edits more easily? Maybe. This first one is awfully ad-hoc, it is literally the result of me copy/pasting links and typing up a bit of prose. You can see the source code here: http://arsdnet.net/this-week-in-d/jan-12.dd But I do certainly want it easy to get contributions, I could try the wiki or github. I'm kinda leaning toward github since I don't actually want it edited once released, then we'll have a more stable look back too. Will there be an archive? Yes, once the links are up I won't take them down and I'll have a list of them on the index page. GitHub for sure!
A naive attempt at a refcounted class proxy
This discussion:
http://forum.dlang.org/thread/bqtcdpsopxmnfbjyr...@forum.dlang.org
-- led me wondering if it would be possible to create some
crippled version of a class proxy that is based on RefCounted and
came up with something like this:
struct Box(T) if (is(T == class)) {
@disable this();
this(Args...)(Args args) {
_payload._refCounted.initialize(new T(args));
}
private {
struct _Box(T) {
private T _instance;
~this() {
destroy(_instance);
}
}
RefCounted!(_Box!T) _payload;
}
~this() {
}
auto opDispatch(string name, Args...)(Args args) {
return mixin(_payload._instance.%s(args).format(name));
}
}
which lets you create Box!SomeClass(args) and it will be
refcounted unless you escape references and do other weird stuff.
It actually sort of seems to work at first glance, at least it
seems like it does... But with my D experience being fairly
limited I wonder what the potential pitfalls would be?
Full source code with example and stdout:
https://gist.github.com/aldanor/d5fb5e45ddf3dd2cb642
Re: D Beginner Trying Manual Memory Management
On Tuesday, 13 January 2015 at 08:33:57 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 12 Jan 2015 22:07:13 + aldanor via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I see, thanks! :) I've started liking structs more and more recently as well and been pondering on how to convert a class-based code that looks like this (only the base class has any data): it's hard to tell by brief description. but having multiple inheritance immediately rings an alarm ring for me. something is very-very-very wrong if you need to have a winged whale. ;-) A real-world example: http://www.hdfgroup.org/HDF5/doc/cpplus_RM/hierarchy.html H5::File is both an H5::Location and H5::CommonFG (but not an H5::Object) H5::Group is both an H5::Object (subclass of H5::Location) and H5::CommonFG H5::Dataset is an H5::Object
Re: Thoughts on replacement languages (Reddit + D)
On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio wrote: On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote: When does invalidMemoryOperationError happen and how do you avoid it? Typical example: using (a slightly outdated version of) gfm library, I have few gfm objects lying around on which I forget to call a close() function. When the GC collects them the destructor runs close(), which in turn calls for some allocation (e.g: allocates for a string to send to the logger), invalidMemoryOperationError pops up. This usually only happens at the end of execution, sometimes however it happens randomly during program execution due to the randomness of GC operations. The only way out of this is manually closing everything correctly. I.e: I'm almost back to C++ manual memory management. Catching the exception is an unsatisfactory solution because I would still be leaking resources[1]. If possible, things are made even worse in that RefCounted doesn't work for classes, but that you can work around that (class instance into refcounted struct, not really elegant and requires lots of discipline, since it's easy to escape an extra reference). [1] For everyone who doesn't know: non trivial destructors are really useful in gfm because it wraps some C libraries, and cleaning up C allocated resources is usually important. Proper execution of gfm's close() for every class would be ideal. Sounds like an exact same problem I have run into recently: class wrappers around HDF5 C library need to do something not @nogc in a destructor and also have to call the C-level releasing functions. Can't do that in a destructor since then you get the invalidMemoryOperationError; can't make classes structs and use refcounted since there's an implied type hierarchy which becomes a mess with alias this... the only way is to put that in close() and then not forget to call it manually. Wish there was a standardized way of running non-@nogc user code before the dtor actually runs (and anytime after it's known to be guaranteed to run).
Re: D Beginner Trying Manual Memory Management
On Monday, 12 January 2015 at 20:30:45 UTC, ketmar via Digitalmars-d-learn wrote: it even has `RefCounted!`, but it doesn't play well with classes yet (AFAIR). I wonder if it's possible to somehow make a version of refcounted that would work with classes (even if limited/restricted in some certain ways), or is it just technically impossible because of reference semantics?
Re: D Beginner Trying Manual Memory Management
On Monday, 12 January 2015 at 21:54:51 UTC, ketmar via
Digitalmars-d-learn wrote:
On Mon, 12 Jan 2015 21:37:27 +
aldanor via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
On Monday, 12 January 2015 at 20:30:45 UTC, ketmar via
Digitalmars-d-learn wrote:
it even has `RefCounted!`, but it doesn't play well with
classes yet
(AFAIR).
I wonder if it's possible to somehow make a version of
refcounted that would work with classes (even if
limited/restricted in some certain ways), or is it just
technically impossible because of reference semantics?
it's hard. especially hard when you considering inheritance
(which is
not playing well with templates) and yes, ref semantics.
on the other side i found myself rarely using classes at all. i
mostly
writing templates that checks if a passed thing has all the
neccessary methods and properties in place and just using that.
with D
metaprogramming abilities (and `alias this` trick ;-)
inheritance
becomes not so important. and so classes too. sometimes i'm
using
structs with delegate fields to simulate some sort of virtual
methods
'cause i tend to constantly forgetting about that `class`
thingy. ;-)
OOP is overrated. at least c++-like (should i say
simula-like?)
OOP. ;-)
I see, thanks! :) I've started liking structs more and more
recently as well and been pondering on how to convert a
class-based code that looks like this (only the base class has
any data):
class Base { T m_variable; }
class Common : Base { /* tons of methods; uses m_variable */ }
class Extra : Base { /* another ton of methods; uses m_variable
*/ }
class A : Extra, Common { ... }
class B : Common { ... }
class C : Extra { ... }
to refcounted structs with alias this but couldn't quite figure
out how to do it (other than use mixin templates...). Even if the
multiple alias this DIP was implemented, I don't think it would
help much here :/
Re: Wrapping a C library with its own GC + classes vs refcounted structs
On Saturday, 10 January 2015 at 20:55:05 UTC, Laeeth Isharc wrote: Hi Aldanor. I wrote a slightly longer reply, but mislaid the file somewhere. I guess your question might relate to wrapping the HDF5 library - something that I have already done in a basic way, although I welcome your project, as no doubt we will get to a higher quality eventual solution that way. One question about accurately representing the HDF5 object hierarchy. Are you sure you wish to do this rather than present a flattened approach oriented to what makes sense to make things easy for the user in the way that is done by h5py and pytables? In terms of the actual garbage generated by this library - there are lots of small objects. The little ones are things like a file access attribute, or a schema for a dataset. But really the total size taken up by the small ones is unlikely to amount to much for scientific computing or for quant finance if you have a small number of users and are not building some kind of public web server. I think it should be satisfactory for the little objects just to wrap the C functions with a D wrapper and rely on the object destructor calling the C function to free memory. On the rare occasions when not, it will be pretty obvious to the user and he can always call destroy directly. For the big ones, maybe reference counting brings enough value to be useful - I don't know. But mostly you are either passing data to HDF5 to write, or you are receiving data from it. In the former case you pass it a pointer to the data, and I don't think it keeps it around. In the latter, you know how big the buffer needs to be, and you can just allocate something from the heap of the right size (and if using reflection, type) and use destroy on it when done. So I don't have enough experience yet with either D or HDF5 to be confident in my view, but my inclination is to think that one doesn't need to worry about reference counting. Since objects are small and there are not that many of them, relying on the destructor to be run (manually if need be) seems likely to be fine, as I understand it. I may well be wrong on this, and would like to understand the reasons if so. Laeeth. Thanks for the reply. Yes, this concerns my HDF5 wrapper project; the main concern is not that the memory consumption of course, but rather explicitly controlling lifetimes of the objects (especially objects like files -- so you are can be sure there are no zombie handles floating around). Most of the time when you're doing some operations on an HDF5 file you want all handles to get closed by the time you're done (i.e. by the time you leave the scope) which feels natural (e.g. close groups, links etc). Some operations in HDF5, particularly those related to linking/unlinking/closing may behave different if an object has any chilld objects with open handles. In addition to that, the C HDF5 library retains the right to reuse both the memory and id once the refcount drops to zero so it's best to be precise about that and keep a registry of weak references to all C ids that D knows about (sort of the same way as h5py does in Python).
Wrapping a C library with its own GC + classes vs refcounted structs
Hi all,
I was wondering what's the most D-idiomatic way of dealing with a
C library (or rather writing wrappers for a C library) that does
its own GC via reference counting. The objects are identified and
passed around by integer ids only; most functions like find me
an object foo in object bar return an id and increase a refcount
internally; in rare cases, a borrowed reference is returned.
Whenever refcount drops to zero, the id becomes invalid and the
memory (and possibly the id as well) gets eventually reused. Some
C functions may explicitly or implicitly release IDs so there's
also a problem of tracking whether a live D object refers to a
live C object.
Since the main concern here is wrapping the C library, the only
data that is stored in D objects is the object id, so the objects
are really lightweight in that sense. However, there's a logical
hierarchy of objects that would be logical to reflect in D types
either via inheritance or struct aliasing.
The main question here is whether it's most appropriate in this
situation to use D classes and cross the fingers relying on D's
GC to trigger C's GC (i.e., ~this() to explicitly decrease
refcount in the C library), or use refcounted structs (or
something else?). I think I understand how RefCounted works but
can't see how exactly it is applicable in cases like this or what
are the consequences of using it.
My initial naive guess was to use classes in D to encapsulate
objects (to be able to use inheritance), so the code for the base
class looks along the lines of:
class ID {
protected int id;
private static shared Registry registry;
this(int id) { // assume that refcount was already increased
in C
this.id = id;
registry.store(this); // store weakref to track zombie
objects
}
~this() @nogc {
if (c_is_valid(id) c_refcount(id) 0)
c_decref(id);
registry.remove(this);
}
}
class ConcreteTypeA(ID) { ... }
class ConcreteTypeB(ID) { ... }
where the weak static registry is required to keep track of live
D objects that may refer to dead C objects and has to be
traversed once in a while.
However there's something sketchy about doing it this way since
the lifetimes of objects are not directly controlled, plus there
are situations where a temporary object is only required to exist
in function's scope and is naturally expected to be released upon
exit from the scope.
A related thread:
http://forum.dlang.org/thread/lmneclktewajznvfd...@forum.dlang.org
Re: Revert attributes to their defaults with default keywords
On Friday, 9 January 2015 at 13:01:14 UTC, Steven Schveighoffer
wrote:
On 1/9/15 7:47 AM, Daniel Kozák via Digitalmars-d wrote:
V Fri, 09 Jan 2015 07:21:02 -0500
Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com
napsáno:
On 1/9/15 6:57 AM, Daniel Kozak wrote:
I often have code like this:
class A {
final:
nothrow:
...
some methods
...
}
Problem comes when I need add methods which for eg.: throws
or need
to be virtual.
I can put them before final: but this is not perfect,
because I
prefer when methods are place in specific order (method abc
call
method asd so asd is bellow abc and so on).
So today I download dmd source and make some small
modification
(only few lines) and this is the result:
http://dpaste.dzfl.pl/472afc938397
Nice, but I don't like the fact that it bluntly returns all
attributes to default.
For example, if you need to remove the final attribute, but
not
nothrow, I'm assuming it looks something like:
default nothrow void foo()
which doesn't read very well.
If we are going to do this, I'd rather see something like has
been
suggested before -- parameterizing attributes:
final(false) - remove final
This allows compile-time booleans to modify attributes in
ways that
are extremely difficult in templates today.
I think both ways shoud be available
when I need remove just one attr than attr!false is nice but
when I
need remove for eg: 3 or more it will look like:
void someFunc final(false) pure(false) nothrow(false)
in this case I think that:
default void foo() nothrow looks OK now :)
I'd rather combine the parameterization with attribute sets
(i.e. aliasing sets of attributes to one symbol). The 'default'
idea is ok, but I think it's too clever -- the word default
doesn't immediately say attributes, so it's going to confuse
people.
-Steve
It could work both ways at the same time.
Maybe even something like default(pred) final(pred) nothrow --
if pred is compile-time-true, reset all attributes and then add
final/nothrow; if it's compile-time-false, disable final and
enable nothrow.
Re: 4x4
On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei Alexandrescu wrote: http://dlang.org/library/std/digest/digest/digest.html Ugh. -- Andrei This thread needs more digest: http://dlang.org/library/std/digest/digest/digest.digest.html
Re: Happy new year!
On Wednesday, 31 December 2014 at 16:55:01 UTC, CraigDillabaugh wrote: On Wednesday, 31 December 2014 at 16:51:45 UTC, Iain Buclaw via Digitalmars-d wrote: On 31 Dec 2014 15:00, Craig Dillabaugh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 31 December 2014 at 14:55:00 UTC, Joseph Rushton Wakeling wrote: On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via Digitalmars-d wrote: Here's to an awesome 2015! Blwyddyn Newydd Dda :-) Is that welsh? That's Cymru to you! Haha, yes. Happy New Year to everyone. Happy New Year, folks!
Re: Order of evaluation of post-increment operator
On Sunday, 28 December 2014 at 14:51:22 UTC, Gary Willoughby
wrote:
I was just taking a look at the following poll[1] about the
order of evaluation when using the post-increment operator. The
following D snippet shows an example.
import std.stdio;
void main(string[] args)
{
auto foo = [0, 0];
int i = 0;
foo[i++] = i++; // Woah!
writefln(%s, foo);
}
Apparently the C++ equivalent is undefined behaviour but when
run using D the following result is output:
[1, 0]
1. Can someone please explain this output?
2. Is there anywhere this order of evaluation is documented?
3. Do you agree this is right?
[1]:
http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation/
Related thread:
http://forum.dlang.org/thread/amngdygrlsogzmefz...@forum.dlang.org#post-l92grb:242q5v:241:40digitalmars.com
Re: Data frames in D?
On Saturday, 27 December 2014 at 10:54:01 UTC, Russel Winder via Digitalmars-d-learn wrote: I know much less about R, but the whole Python/NumPy thing works but only because it is faster and easier than Python alone. NumPy performance is actually quite poor. I am finding I can write Python + Numba code that hugely outperforms that same algorithm using NumPy. There will sure be some algorithms where numba/cython would do better (especially if they cannot be easily vectorized), but that's not the point. The thing about numpy is that it provides a unified accepted interface (plus a reasonable set of reasonably fast tools and algorithms) for arrays and buffers for a multitude of scientific libraries (scipy, pytables, h5py, pandas, scikit-*, just to name a few), which then makes it much easier to use them together and write your own ones.
Re: Constructor protection: package ctors, UFCS, static methods?
On Friday, 26 December 2014 at 15:58:18 UTC, aldanor wrote: Please ignore the missing new keywords in the code and other minor typos :) Any opinions please?.. Would be much appreciated. Thanks!
nogc associative array?
Is there a way to do something like this while keeping the
destructor nogc?
class Foo {
shared static Foo[id] registry;
int id;
this(int id) {
this.id = id(
registry[id] = this;
}
~this() }. // ideally should be tagged as @nogc
// nasty, memory corruption due to gc
registry.remove(id)f;
// however compiler doesn't warn about it...
}
}
Constructor protection: package ctors, UFCS, static methods?
Hi, I've been wondering if anyone would give some advice on an
OOP-related question. Assume there's an external library (module
c_library) that handles IDs for groups and datasets and we want
to wrap it in a high-level D API. Groups can contain datasets
identified by names, and each dataset has a parent group; there
are external functions get_dataset/get_group that provide the
corresponding ids.
The Group class needs to have a dataset(name) method that
returns a dataset by name and the Dataset needs to have a
group() method that returns the parent group. However
constructors of Group and Dataset that take an id are really
meant to be completely internal (i.e. private or protected) which
leads to the problem: how would those methods be able to access
those constructors?
--
Solution 1: set protection level for constructors of
Group/Dataset to package so they are callable from anywhere in
the package. This feels a bit wrong though as they are really
meant to be protected; this is also an exploit of the D-specific
package qualifier so e.g. one wouldn't be able to do something
like this in C++.
/* id.d */
class ID {
protected int m_id;
protected this(int id) {
m_id = id;
}
int id() @property const {
return m_id;
}
}
/* group.d */
import c_library : get_dataset;
import id : ID;
import dataset : Dataset;
class Group : ID {
package this(int id) { super(id); } // -- package
public this(...) { // high-level public ctor }
Dataset getDataset(string name) const {
int dataset_id = get_dataset(this.id, name);
return Dataset(dataset_id);
}
/* dataset.d */
import c_library : get_group;
import id : ID;
import group : Group;
class Dataset : ID {
package this(int id) { super(id); } // -- package
public this(...) { // high-level public ctor }
Group group() const {
int group_id = get_group(this.id);
return Group(group_id);
}
}
--
Solution 2: use UFCS and swap the group() / dataset(name)
functions between the two modules. This way, e.g. group() will
have access to protected Group.this(id) due to being in the same
module. However, now there's a different problem: if you import
group, you won't be able to do a group.dataset(name) due to it
being in a different module, so a public import is required to
fix that -- which also feels a bit ugly (what if there are 15
different modules and not 2, would they all have to
cross-public-import each other?). This is also a D-specific
exploit so it again wouldn't be possible in C++.
/* group.d */
import c_library : get_group;
import id : ID;
public import dataset; // -- public import due to UFCS
class Group : ID {
protected this(int id) { super(id); } // -- protected
}
Group group(in Dataset dataset) {
return Group(get_group(dataset.id));
}
/* dataset.d */
import c_library : get_dataset;
import id : ID;
public import group; // -- public import due to UFCS
class Dataset : ID {
protected this(int id) { super(id); } // -- protected
}
Dataset dataset(in Group group, string name) {
return new Dataset(get_dataset(group.id, name));
}
--
Solution 3: add static methods like Dataset::fromGroup(name) and
Group::fromDataset() and then do something like this:
/* group.d */
class Group : ID {
...
static typeof(this) fromDataset(in Dataset dataset) {
return new typeof(this)(get_group(dataset.id));
}
}
/* dataset.d */
class Dataset {
...
Group group() @property const {
return Group.fromDataset(this);
}
}
However, this essentially leads to duplications of every such
lookup methods, so if there are many such entities, there will be
a whole bunch of such static methods..
--
Is this a completely normal situation or is the design flawed and
there's a clean way around it?
Thanks!
Re: Constructor protection: package ctors, UFCS, static methods?
Please ignore the missing new keywords in the code and other minor typos :)
Re: D language manipulation of dataframe type structures
On Wednesday, 25 September 2013 at 03:41:36 UTC, Jay Norwood wrote: I've been playing with the python pandas app enables interactive manipulation of tables of data in their dataframe structure, which they say is similar to the structures used in R. It appears pandas has laid claim to being a faster version of R, but is doing so basically limited to what they can exploit from moving operations back and forth from underlying cython code. Has anyone written an example app in D that manipulates dataframe type structures? Pandas has numpy as backend which does a lot of heavy lifting, so first things first -- imo D needs a fast and flexible blas/lapack-compatible multi-dimensional rectangular array library that could later serve as backend for pandas-like libraries.
Throw an exception but hide the top frame?
Imagine there's a template that wraps arbitrary functions and may
throw exceptions depending on their returned values (see a
simplified example below). However, if an exception occurs, the
backtrace is pointing inside the template which is not helpful at
all (especially when many such functions have been wrapped). Is
it somehow possible to throw an exception from the parent frame
so the backtrace would never drop into the template body?
Here's an example:
module wrap;
import std.stdio;
import std.string;
auto check(alias func)(int x) {
auto result = func(x);
if (result 0) // throw on negative return value
throw new Exception(%d 0.format(result)); // L10
return x; // otherwise, pass the result through
}
int f(int x) {
return !(x % 2) ? x : -x;
}
void main() {
import std.stdio;
alias g = check!f;
writeln(g(2)); // ok
writeln(g(3)); // should fail // L21
}
which prints something lke this when run:
2
object.Exception@wrap.d(10): -3 0
.. (int wrap.check!(_D4wrap1fFiZi).check(int)+0x13) [0x44cf87]
.. (_Dmain+0x20) [0x448da4]
Is it possible to throw an exception in a way that backtrace
would be more like this?
2
object.Exception@wrap.d(21): -3 0
.. (_Dmain+0x20) [0x448da4]
Re: Throw an exception but hide the top frame?
On Wednesday, 24 December 2014 at 13:48:26 UTC, ketmar via
Digitalmars-d-learn wrote:
the `object.Exception@wrap.d` is not a backtrace result, this
is the
result of Exception class constructor:
this (string msg, string file=__FILE__, usize line=__LINE__,
Throwable next=null)
it registering the file and line of exception object creation in
COMPILE time. so you can do nothing with it, as there is no way
to know
what called what in compile time.
p.s. if you can use GDC, for example, and turn on debug info,
backtrace will show you files and line numbers for every
address.
Hmm, that makes sense. After some pondering, I think I've hacked
together a workaround though:
template check(alias func) {
auto check(string file = __FILE__, int line =
__LINE__)(int x) {
auto result = func(x);
if (result 0) // throw on negative return vaule
throw new Exception(%d 0.format(result),
file, line);
return x; // otherwise, pass the result through
}
}
which produces:
2
object.Exception@wrap.d(23): -3 0
.. (_Dmain+0x20) [0x448de4]
Are there any hidden downsides to doing it this way (aside from
generating additional code on every call)?
Re: Throw an exception but hide the top frame?
On Wednesday, 24 December 2014 at 14:11:37 UTC, Adam D. Ruppe
wrote:
auto check(alias func)(int x, string file = __FILE__, size_t
line = __LINE__) {
/* snip */
throw new Exception(%d 0.format(result), file,
line); // L10
Thanks! I guess that's what my confusion was partially about --
when exactly the __FILE__ and __LINE__ are substituted
(particularly in the case when you're dealing with templates).
It looks like this would even work with generic callables:
auto check(alias func)(ParameterTypeTuple!(func) args, string
__line__ = __LINE__, int __file__ == __FILE__) {
static if (is(ReturnType!(func) == void))
func(args);
else {
auto result = func(args);
if (result 0)
throw new Exception(foo, __line__, __file__);
return result;
}
}
Templates, constructors and default arguments
I'm wondering how to best implement the following pattern: the constructor of a class has some required and some optional arguments; and one of the (optional) arguments also controls if any additional arguments should be passed. A hypothetical/simplified example that I came up with: there's a Dataset class which requires size and rank to be set. Size is required; rank defaults to 1. There's also a filebacked boolean option that defaults to false; if specified, a bunch of additional arguments are available (like filename, mode, etc), some of which have default values. Ideally, I'd want to be able to construct it like this: // new Dataset could instead be a static factory method like Dataset.create // this is is purely hypothetical new Dataset; // fails, size required new Dataset(size); // filebacked=false, rank=1 new Dataset(size, rank); // filebacked=false new Dataset(size, rank, foo); // fails, filename not applicable new Dataset!false(size); // rank=1 new Dataset!true(size, rank); // fails, filename missing new Dataset!true(size, rank, foo); // mode = w+ new Dataset!true(size, rank, foo, w+); If the filebacked argument only affects construction of the object and not its runtime behaviour, creating subclasses to solve this seems somewhat wrong. In fact, this argument doesn't even have to be a compile-time value but for the sake of being able to catch errors at compile time it probably should be. Templating the class like this class Dataset(filebacked = false) doesn't work since then new Dataset(size) is disallowed, in favor of Dataset!()(size). Adding a template factory function with variadic arg tuple like so Dataset create(bool filebacked = false, Args...)(uint size, uint rank = 1, Args args) doesn't work either because of the presence of default parameters (default argument expected for args). I wonder if there's any way to hack around this?
Re: Templates, constructors and default arguments
On Thursday, 25 December 2014 at 02:28:47 UTC, ketmar via Digitalmars-d-learn wrote: happy hacking! ;-) Thanks once again! I think this mostly solves it. Would it be possible to somehow do the same trick with this()? (I guess due to having to write Type!() when default template arguments are omitted?)
Re: Walter's DConf 2014 Talks - Topics in Finance
On Tuesday, 23 December 2014 at 07:51:18 UTC, Oren Tirosh wrote: On Saturday, 22 March 2014 at 12:06:37 UTC, Russel Winder wrote: On Sat, 2014-03-22 at 00:14 +, Daniel Davidson wrote: […] Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately. I would certainly agree that (at least initially) pitching D against the Excel/Python/R/Julia/Mathematica is an easier fight. The question is how to convince someone to take the first step. In that case, a good start might be a D kernel for IPython/Jupyter. Seeing an interactive D REPL session inside a notebook should make a pretty convincing demo. That's an interesting idea, how would you approach it though with a compiled non-functional language? Maybe in the same way the %%cython magic is done?
Tuple opAssign type deduction
alias T = Tuple!(int, a, double, b); T foo = [1, 2]; // works T bar; bar = [1, 2]; // doesn't? Wonder if there's an obvious reason to this?
Re: Rectangular multidimensional arrays for D
A gap in multi-dimensional rectangular arrays functionality in D is sure a huge blocker when trying to use it for data science tasks. Wonder what's the general consensus on this?
Re: Davidson/TJB - HDF5 - Re: Walter's DConf 2014 Talks - Topics in Finance
On Monday, 22 December 2014 at 08:35:59 UTC, Laeeth Isharc wrote: On Saturday, 22 March 2014 at 14:33:02 UTC, TJB wrote: On Saturday, 22 March 2014 at 13:10:46 UTC, Daniel Davidson wrote: Data storage for high volume would also be nice. A D implementation of HDF5, via wrappers or otherwise, would be a very useful project. Imagine how much more friendly the API could be in D. Python's tables library makes it very simple. You have to choose a language to not only process and visualize data, but store and access it as well. Thanks Dan Well, I for one, would be hugely interested in such a thing. A nice D API to HDF5 would be a dream for my data problems. Did you use HDF5 in your finance industry days then? Just curious. TJB Well for HDF5 - the bindings are here now - pre alpha but will get there soone enough - and wrappers coming along also. Any thoughts/suggestions/help appreciated. Github here: https://github.com/Laeeth/d_hdf5 I wonder how much work it would be to port or implement Pandas type functionality in a D library. @Laeeth As a matter of fact, I've been working on HDF5 bindings for D as well -- I'm done with the binding/wrapping part so far (with automatic throwing of D exceptions whenever errors occur in the C library, and other niceties) and am hacking at the higher level OOP API -- can publish it soon if anyone's interested :) Maybe we can join efforts and make it work (that and standardizing a multi-dimensional array library in D).
Re: Walter's DConf 2014 Talks - Topics in Finance
On Monday, 22 December 2014 at 12:24:52 UTC, Laeeth Isharc wrote: In case it wasn't obvious from the discussion that followed: finance is a broad field with many different kinds of creature within, and there are different kinds of problems faced by different participants. High Frequency Trading has peculiar requirements (relating to latency, amongst other things) that will not necessarily be representative of other areas. Even within this area there is a difference between the needs of a Citadel in its option marketmaking activity versus the activity of a pure delta HFT player (although they also overlap). A JP Morgan that needs to be able to price and calculate risk for large portfolios of convex instruments in its vanilla and exotic options books has different requirements, again. You would typically use Monte Carlo (or quasi MC) to price more complex products for which there is not a good analytical approximation. (Or to deal with the fact that volatility is not constant). So that fits very much with the needs of large banks - and perhaps some hedge funds - but I don't think a typical HFT guy would be all that interested to know about this. They are different domains. Quant/CTA funds also have decent computational requirements, but these are not necessarily high frequency. Winton Capital, for example, is one of the larger hedge funds in Europe by assets, but they have talked publicly about emphasizing longer-term horizons because even in liquid markets there simply is not the liquidity to turn over the volume they would need to to make an impact on their returns. In this case, whilst execution is always important, the research side of things is where the value gets created. And its not unusual to have quant funds where every portfolio manager also programs. (I will not mention names). One might think that rapid iteration here could have value. http://www.efinancialcareers.co.uk/jobs-UK-London-Senior_Data_Scientist_-_Quant_Hedge_Fund.id00654869 Fwiw having spoken to a few people the past few weeks, I am struck by how hollowed-out front office has become, both within banks and hedge funds. It's a nice business when things go well, but there is tremendous operating leverage, and if one builds up fixed costs then losing assets under management and having a poor period of performance (which is part of the game, not necessarily a sign of failure) can quickly mean that you cannot pay people (more than salaries) - which hurts morale and means you risk losing your best people. So people have responded by paring down quant/research support to producing roles, even when that makes no sense. (Programmers are not expensive). In that environment, D may offer attractive productivity without sacrificing performance. I agree with most of these points. For some reason, people often relate quant finance / high frequency trading with one of the two: either ultra-low-latency execution or option pricing, which is just wrong. In most likelihood, the execution is performed on FPGA co-located grids, so that part is out of question; and options trading is just one of so many things hedge funds do. What takes the most time and effort is the usual data science (which in many cases boil down to data munging), as in, managing huge amounts of raw structured/unstructured high-frequency data; extracting the valuable information and learning strategies; implementing fast/efficient backtesting frameworks, simulators etc. The need for efficiency here naturally comes from the fact that a typical task in the pipeline requires dozens/hundreds GB of RAM and dozens of hours of runtime on a high-grade box (so noone would really care if that GC is going to stop the world for 0.05 seconds). In this light, as I see it, D's main advantage is a high runtime-efficiency / time-to-deploy ratio (whereas one of the main disadvantages for practitioners would be the lack of standard tools for working with structured multidimensional data + linalg, something like numpy or pandas). Cheers.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Monday, 22 December 2014 at 17:28:39 UTC, Daniel Davidson wrote: I don't see D attempting to tackle that at this point. If the bulk of the work for the data sciences piece is the maths, which I believe it is, then the attraction of D as a data sciences platform is muted. If the bulk of the work is preprocessing data to get to an all numbers world, then in that space D might shine. That is one of my points exactly -- the bulk of the work, as you put it, is quite often the data processing/preprocessing pipeline (all the way from raw data parsing, aggregation, validation and storage to data retrieval, feature extraction, and then serialization, various persistency models, etc). One thing is fitting some model on a pandas dataframe on your lap in an ipython notebook, another thing is running the whole pipeline on massive datasets in production on a daily basis, which often involves very low-level technical stuff, whether you like it or not. Coming up with cool algorithms and doing fancy maths is fun and all, but it doesn't take nearly as much effort as integrating that same thing into an existing production system (or developing one from scratch). (and again, production != execution in this context) On Monday, 22 December 2014 at 17:28:39 UTC, Daniel Davidson wrote: What is a backtesting system in the context of Winton Capital? Is it primarily a mathematical backtesting system? If so it still may be better suited to platforms focusing on maths. Disclaimer: I don't work for Winton :) Backtesting in trading is usually a very CPU-intensive (and sometimes RAM-intensive) task that can be potentially re-run millions of times to fine-tune some parameters or explore some sensitivities. Another common task is reconciling with how the actual trading system works which is a very low-level task as well.
Re: Rectangular multidimensional arrays for D
On Monday, 22 December 2014 at 22:36:16 UTC, H. S. Teoh via Digitalmars-d wrote: FYI, Kenji's merge has since been merged. So now the stage is set for somebody to step up and write a nice multidimensional array implementation. One important thing to wish for, in my opinion, is that the design of such implementation would allow for (future potential) integration with linear algebra libraries like blas/lapack without having to be rewritten from scratch (e.g. so it doesn't end up like Python's array module which got completely superceded by numpy).
Re: math.log() benchmark of first 1 billion int using std.parallelism
On Monday, 22 December 2014 at 11:11:07 UTC, aldanor wrote:
Just tried it out myself (E5 Xeon / Linux):
D version: 19.64 sec (avg 3 runs)
import core.stdc.math;
void main() {
double s = 0;
foreach (i; 1 .. 1_000_000_000)
s += log(i);
}
// build flags: -O -release
C version: 19.80 sec (avg 3 runs)
#include math.h
int main() {
double s = 0;
long i;
for (i = 1; i 10; i++)
s += log(i);
return 0;
}
// build flags: -O3 -lm
Replacing import core.stdc.math with import std.math in the D
example increases the avg runtime from 19.64 to 23.87 seconds
(~20% slower) which is consistent with OP's statement.
Re: math.log() benchmark of first 1 billion int using std.parallelism
On Monday, 22 December 2014 at 10:40:45 UTC, Daniel Kozak wrote:
On Monday, 22 December 2014 at 10:35:52 UTC, Daniel Kozak via
Digitalmars-d-learn wrote:
I run Arch Linux on my PC. I compiled D programs using
dmd-2.066 and used no compile arguments (dmd prog.d)
You should try use some arguments -O -release -inline
-noboundscheck
and maybe try use gdc or ldc should help with performance
can you post your code in all languages somewhere? I like to
try it on
my machine :)
Btw. try use C log function, maybe it would be faster:
import core.stdc.math;
Just tried it out myself (E5 Xeon / Linux):
D version: 19.64 sec (avg 3 runs)
import core.stdc.math;
void main() {
double s = 0;
foreach (i; 1 .. 1_000_000_000)
s += log(i);
}
// build flags: -O -release
C version: 19.80 sec (avg 3 runs)
#include math.h
int main() {
double s = 0;
long i;
for (i = 1; i 10; i++)
s += log(i);
return 0;
}
// build flags: -O3 -lm
Re: math.log() benchmark of first 1 billion int using std.parallelism
On Monday, 22 December 2014 at 17:28:12 UTC, Iov Gherman wrote: So, I did some more testing with the one processing in paralel: --- dmd: 4 secs, 977 ms --- dmd with flags: -O -release -inline -noboundscheck: 4 secs, 635 ms --- ldc: 6 secs, 271 ms --- gdc: 10 secs, 439 ms I also pushed the new bash scripts to the git repository. import std.math, std.stdio, std.datetime; -- try replacing std.math with core.stdc.math.
Re: Inheritance and in-contracts
https://github.com/D-Programming-Language/dmd/pull/4200
Re: Inheritance and in-contracts
On Monday, 22 December 2014 at 19:11:13 UTC, Ali Çehreli wrote: On 12/22/2014 10:06 AM, aldanor wrote: https://github.com/D-Programming-Language/dmd/pull/4200 Thank you! This fixes a big problem with the contracts in D. Ali It's not my PR but I just thought this thread would be happy to know :)
Re: What's missing to make D2 feature complete?
- static foreach (declaration foreach) - fixing __traits templates (eg getProtection vein extremely flaky, allMembers not working etc) -- seeing as ctfe is one of flagship features of D, it would make sense to actually make it work flawlessly.
Re: allMembers returns no members for a package
On Friday, 19 December 2014 at 12:06:08 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 19 Dec 2014 02:12:40 +
aldanor via Digitalmars-d digitalmars-d@puremagic.com wrote:
pkg/
c/
module1.d
module pkg.c.module1;
int x = 1;
package.d
module pkg.c;
public import pkg.c.module1;
test.d
module pkg.test;
unittest {
import std.stdio;
import pkg.c;
writeln(pkg.c.x);
writeln(__traits(allMembers, pkg.c));
}
Results in 1 printed and then nothing.
Why does allMembers fail on a package, is that supposed to
happen?
this is a known issue (sorry, can't remember bug number, and
search in
bugzilla never worked for me for some mysterious reason). this
will
eventually be fixed, but don't expect it soon, it's not a
high-priority
issue.
I see, thanks. Is there an open tracker issue for this?
What's even more weird is that in some cases it does work (but
most likely doesn't) and I can't seem to figure out what's the
defining factor.
Re: Loops versus ranges
On Friday, 19 December 2014 at 10:41:04 UTC, bearophile wrote:
A case where the usage of ranges (UFCS chains) leads to very
bad performance:
import std.stdio: writeln;
import std.algorithm: map, join;
uint count1, count2;
const(int)[] foo1(in int[] data, in int i, in int max) {
count1++;
if (i max) {
typeof(return) result;
foreach (immutable n; data)
result ~= foo1(data, i + 1, max);
return result;
} else {
return data;
}
}
const(int)[] foo2(in int[] data, in int i, in int max) {
count2++;
if (i max) {
return data.map!(n = foo2(data, i + 1, max)).join;
} else {
return data;
}
}
void main() {
const r1 = foo1([1, 2, 3, 4, 5], 1, 7);
writeln(count1); // 19531
const r2 = foo2([1, 2, 3, 4, 5], 1, 7);
writeln(count2); // 111
assert(r1 == r2); // Results are equally correct.
}
Can you tell why? :-)
Bye,
bearophile
Something about the loop in the first case not depending on n and
the compiler being able to figure it is out and only drop into
recursion once?
Re: Loops versus ranges
On Friday, 19 December 2014 at 10:57:47 UTC, aldanor wrote: Something about the loop in the first case not depending on n and the compiler being able to figure it is out and only drop into recursion once? That's just a wild guess, but does it get transformed into something like this? typeof(return) result; typeof(return) tmp = foo1(data, i + 1, max); foreach (immutable n; data) result ~= tmp;
allMembers returns no members for a package
pkg/
c/
module1.d
module pkg.c.module1;
int x = 1;
package.d
module pkg.c;
public import pkg.c.module1;
test.d
module pkg.test;
unittest {
import std.stdio;
import pkg.c;
writeln(pkg.c.x);
writeln(__traits(allMembers, pkg.c));
}
Results in 1 printed and then nothing.
Why does allMembers fail on a package, is that supposed to happen?
Re: Referring to alias parameters in a mixin template
On Wednesday, 17 December 2014 at 12:49:10 UTC, anonymous wrote:
As far as I understand, the string mixin is resolved first, and
then the template mixin takes place. So the progression is
somewhat like this (pseudo code):
mixin makeProperty!(int, foo, f);
/* Replace makeProperty with its definition. */
mixin (T, name, func){mixin(T %s() @property { return
func();}.format(name));}!(int, foo, f);
/* First round, substitute arguments for parameters. `T` and
`func` are not replaced, because they're just string contents at
this point. */
mixin (T, name, func){mixin(T %s() @property { return
func();}.format(foo));}!(int, foo, f);
/* Evaluate `format` and do the string mixin. */
mixin (T, name, func){T foo() @property { return func();}}!(int,
foo, f);
/* Second round, substitute arguments for parameters. This time,
`T` and `func` are replaced. */
mixin (T, name, func){int foo() @property { return f();}}!(int,
foo, f);
/* Didn't do any string mixins in the second round, so there's
no
need for a third round. Get rid of template parameters and
arguments. */
mixin {int foo() @property { return f();}};
/* Finally, do the template mixin. */
int foo() @property { return f();}
Not sure if that helps or maybe it just adds to the confusion.
As to if there were `T` or `func` in the target scope, they'd be
shadowed by the template parameters, no matter if there's a
string mixin or not.
That makes sense. So if I understand correctly, basically after
each string mixin it has to check if any new symbols were leaked
into the current scope and then try to resolve them, if any, with
template parameters taking precedence over local variables? (This
obviously has to repeat in case of nested mixins)
Thanks again!
A mixin template for automatic property generation (criticize my code?)
I'm trying (hard) to learn D templating, and (thanks to the great
help on this forum) I've been able to solve one of the recent
tasks I've been struggling about for a while. Wonder if anyone
would take a moment to criticize the code so we rookies could
learn?
Could this be done more elegantly?
P.S. will there ever be a static foreach for declarations?..
P.P.S. this is a great community, thanks again for all who
answered to my previous questions :)
Task at hand: there's a bunch of private variables (extern
globals from a C library) scattered across a number of modules
whose definitions look like this:
private extern (C) __gshared int foo_g;
private extern (C) __gshared long bar_g;
for which one needs to generate module-level accessors like these:
int foo() @property {
func();
return foo_g;
}
long bar() @property {
func();
return bar_g;
}
where func is some callable.
Ideally, it would be done like so:
mixin makeModuleProperties(_g, func);
and it should respect qualified names and work across modules
(that was the biggest problem -- just generating a huge code
string and mixing it in turned out to be too fragile with respect
to fully qualified names, and quite a mess in general).
Solution:
import std.traits;
import std.string;
import std.typetuple;
template ID(alias T) {
alias ID = T;
}
private bool _propertyNameMatches(alias parent, string
suffix, alias name)() {
static if (!__traits(compiles, __traits(getMember,
parent, name)))
return false;
else {
alias symbol = ID!(__traits(getMember, parent, name));
enum name = __traits(identifier, symbol);
enum n = suffix.length;
static if (!is(symbol) is(typeof(symbol))) //
variables only
return (name.length n) (name[$ - n .. $] ==
suffix);
else
return false;
}
}
private mixin template _makeProperty(alias parent, string
suffix, alias func, string name) {
mixin((typeof(__traits(getMember, parent, name)) %s()
@property
~ { func(); return __traits(getMember, parent,
name); }).format(
name[0 .. $ - suffix.length]));
}
private mixin template _makeProperties(alias parent, string
suffix, alias func, names...) {
static if (names.length 0) {
static if (_propertyNameMatches!(parent, suffix,
names[0]))
mixin _makeProperty!(parent, suffix, func,
names[0]);
mixin _makeProperties!(parent, suffix, func, names[1
.. $]);
}
}
mixin template makeProperties(alias parent, string suffix,
alias func = {}) {
static if (__traits(compiles, __traits(allMembers,
parent)))
mixin _makeProperties!(parent, suffix, func,
__traits(allMembers, parent));
}
mixin template makeModuleProperties(string suffix, alias func
= {}) {
mixin makeProperties!(mixin(__MODULE__), suffix, func);
}
unittest {
struct Foo {
static int x_g = 1;
static int y_g = 2;
static int z = 3;
static mixin makeProperties!(Foo, _g);
}
int counter = 0;
mixin makeProperties!(Foo, _g, { counter++; });
assert(Foo.x == 1);
assert(Foo.y == 2);
assert(x == 1);
assert(counter == 1);
assert(y == 2);
assert(counter == 2);
static assert(!is(typeof(z)));
}
Re: A mixin template for automatic property generation (criticize my code?)
I've no idea why the forum decided to wrap all code; anyway: https://gist.github.com/aldanor/ddc45b2710a2deb9ee2b
Re: mixin template and const property qualifier?
On Monday, 15 December 2014 at 23:21:05 UTC, anonymous wrote:
On Monday, 15 December 2014 at 23:14:30 UTC, aldanor wrote:
Could someone please explain why the following doesn't compile
with const qualifier while it does work without it?
/* test.d */
module test;
mixin template Foo() {
mixin(@property int bar() const { return foo; });
}
int foo = 1;
mixin Foo;
unittest {
assert(foo == bar);
}
rdmd -main -unittest test.d
test.d-mixin-4(4): Error: function test.Foo!().bar without
'this' cannot be const
test.d(9): Error: mixin test.Foo!() error instantiating
Has nothing to do with mixin. This produces the same error
message:
@property int bar() const { return foo; }
int foo = 1;
unittest {assert(foo == bar);}
The thing is, free functions cannot be const. In a const method,
what's const is `this`. A free function doesn't have `this`, so
it cannot be const.
Indeed... thanks!
Referring to alias parameters in a mixin template
Would something like this be possible at all? A hypothetical
mixin template
mixin template makeProperty(T, string name, alias func) {
...
}
that could be called like this:
makeProperty!(int, foo, f)
and would generate code like
int @property foo() { return f(); }
This is a very simplified example of what I'm trying to do, but
I'm a bit stuck at this point -- if I'm generating the code as a
string, how do I know how to refer to func alias (traits
identifier / fullyQualifiedName just don't cut it for a lot of
cases)? For one, thing, it could be an anonymous delegate like {
return 0; } or symbol from another module or anything else. This
is obviously doable if func is a string that gets mixed in, but
what if it is an alias?
Without the name part, one could sure use a simple template:
template makeUnnamedProperty(T, alias func) {
T makeUnnamedProperty() @property { return func(); }
}
and then this works...
alias foo = makeUnnamedProperty!(int, f);
However, how does the one go about templating this when foo is
a (compile-time) string?
Wonder if I'm missing something...
Thanks.
Re: Referring to alias parameters in a mixin template
A partial solution would be something like this:
mixin template makeProperty(T, string name, alias func) {
enum p = makeUnnamedProperty!(T, func);
mixin(enum %s = p;.format(name)); // or alias
}
however now the parent namespace is polluted with p, is there
any way to hide it away and/or avoid it?
I may be wrong, but I guess the whole thing boils down to a
question whether it's possible to have a mixin template with
signature 'bind(string name, alias symbol)' which generates 'enum
foo = bar;' when called as 'mixin bind!(foo, bar)'?
Re: Referring to alias parameters in a mixin template
On Wednesday, 17 December 2014 at 01:39:07 UTC, anonymous wrote:
But if you want to avoid `p`, just do the substitution:
mixin template makeProperty(T, string name, alias func) {
mixin(enum %s = makeUnnamedProperty!(T,
func);.format(name)); // or alias
}
Thanks, that looks exactly like what I need -- I figured
something like this would compile, but I guess it's slightly
counterintuitive that you can access T and 'func this way.
Wonder if this is doable within a single mixin template without
using makeUnnamedProperty?
Re: Referring to alias parameters in a mixin template
On Wednesday, 17 December 2014 at 02:12:52 UTC, anonymous wrote:
Sure, straight forward:
mixin template makeProperty(T, string name, alias func) {
mixin(T %s() @property { return func();
}.format(name));
}
Indeed... thanks! Just one thing that I find confusing here -- how
exactly do T and func resolve when this template is mixed in?
What if there was another local symbol named func in the target
scope?
mixin template and const property qualifier?
Could someone please explain why the following doesn't compile
with const qualifier while it does work without it?
/* test.d */
module test;
mixin template Foo() {
mixin(@property int bar() const { return foo; });
}
int foo = 1;
mixin Foo;
unittest {
assert(foo == bar);
}
rdmd -main -unittest test.d
test.d-mixin-4(4): Error: function test.Foo!().bar without 'this'
cannot be const
test.d(9): Error: mixin test.Foo!() error instantiating
Wrapping multiple extern (C) declarations in a template
I'm writing bindings to a rather big C library where the return
values of almost all functions indicate the possibility of an
error (exception).
Assuming there's a C header, foo.h with functions f1, f2,
etc, I want to have a corresponding D module, foo.d which would
provide the f1, f2 that wrap the C functions and throw
exceptions if an error is encountered (which is implemented in an
errorCheck template which checks the return value and then gets
the exception info via C API).
My current naive solution looks like this:
/* foo.h */
int f1(...);
int f2(...);
*** foo.d ***
private extern (C) nothrow {
pragma(mangle, f1)
int c_f(...);
public alias errorCheck!c_f1 f1;
pragma(mangle, f2)
int c_f2(...);
public alias errorCheck!c_f2 f2;
}
This way, one can import foo and use the same API as in C, but
with proper exception handling.
Since there is almost a thousand declarations, this leads to a
lot of manual work and boilerplate. I guess the wrapping part
itself (aliasing the wrapped functions) could be automated via a
mixin template, but how would one go around repetitive
pragma(mangle) (which I thought is needed so that private extern
declarations have different names and don't clash with the
wrapped ones )?
Re: Wrapping multiple extern (C) declarations in a template
Personally i wouldn't go this route. I would create foo.d as a C to D translation only so it can be imported and used like in C. Then i would create another module which imports this to create your new OOP API adding features and excepions, etc. This allows the best of both worlds, keep the C api intact for use in D and create a new clean OOP API for whatever your needs are. I've actually done it this way initially, as well, however there are certain problems. Let's say there's a foo.d that contains raw bindings to foo.h (enums, structs, extern variables, function declarations, a whole load of stuff) -- everything but the functions is already fine but all functions need to be wrapped. If I now want to have exactly the same module but with all function declarations wrapped as described above, I have to public import it in another module and then do some template magic. However, it wouldn't be possible to retain the same function names since they've been imported to the namespace (it's then also not possible to extern them as private initially since then you won't be able to import/wrap them in a different module). Hence the idea of mixing the wrapping template in the initial .d header. I guess another way would be to split each header into functions / non-functions part, and private import + wrap the first part and public import the second part into a D-ready module. It just sounds like a whole lot of boilerplate so I was hoping there would be some magic automated way of doing something similar (maybe creating a custom import template that imports non-functions via aliasing and wraps functions)...
