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: D on Slashdot
On Fri, 23 Jan 2015 12:50:31 +, Kagamin wrote: On Thursday, 22 January 2015 at 16:13:31 UTC, ketmar wrote: somehow i can't close cmd.exe by hitting ctrl+c. don't console programs know what ctrl+c is for? Well, maybe because it's a shell, not a utility? shell is a console utility. Hmm... shell is a user interface providing access to the system and utilities. It's different from user utilities in that it's a system component, making the whole thing usable at all. i can use my system without shell at all. it's in no way system component, nor even critical system component. it's a simple interpreter, which is not even necessary. a console utility. It shouldn't terminate conventionally, because then the user remains without access to the system i ran sh in sh. how terminating second sh will leave me without access to the system? that's why console shell doesn't terminate on ctrl-c and GUI shell doesn't terminate on alt-f4. But a text editor should definitely terminate in a conventional manner. oh, how about init=/usr/bin/vi? look ma, vi is my shell now! strangely, ctrl+c is not working in FAR too. it's not a shell. it's obvious console. Maybe they just don't give a shit about it? Or they see it as a shell. Truth be told, FAR has a quit button at the bottom. trush be told, vi has a quit command. i can't see why FAR is so different from vi so it can ignore ctrl+c, and vi can't. just 'cause it's SPARTA^W FAR? Well, that's your implementation. In fact shift-tab returns the previous entry. It's a popular reversal modifier, e.g. in a tabbed browser ctrl-t opens a new tab and ctrl-shift-t opens previously closed tab, in a text editor ctrl-z is undo and ctrl-shift-z is redo. it's good for windows-like systems that they appeared so late, so they don't know what the hell those terminals was. hint: not every terminal was able to distinguish between tab, shift+tab, ctrl+tab, etc. console utility must remain usable on those things. The term has nothing to do with windows, it's from theory of programming languages, such things usually tend to be quite old, maybe even older than unix. ok. it's string literal, as opposed to filename literal. string literals are not subjects of autocompletion. Well, it's not really needed. User only types the first characters without quotes, no need for them really; then quotes are added by the autocompletion algorithm, if needed. effectively turning filename literal to string literal and breaking autocompletion. brilliant! the reason why quoted strings can't be autocompleted is 'cause when you start typing 'em, they are syntatically incorrect: they missing closing quote. if you'll add closing quote, they *can't* be autocompleted, 'cause they are already complete -- you indicated that with closing quote. there is no sense in trying to do all that guesswork. As I explained, the file can start with a difficult to type character, requiring to type it is unnecessarily daunting. and you know what? if you hit tab twice on empty line in bash, you'll eventually see something like this: Display all 4788 possibilities? (y or n) good luck browsing thru that. On windows you can choose to iterate through some first of them or try something else. There are extreme cases, but they are, well, extreme. User folders are likely to have small number of files. hitting tab in empty line must give you list of *ALL* possible commands. cmd doesn't do that? then it's broken. yes, my system has 4788 commands that i can invoke from command line. and yes, typing cat and hitting tab twice will show you the list of all files in the current directory. and once again i must tell you about zsh, which has alot of nice UI enhancements. and sure, you can write custom autocompleters for bash and zsh, using their shell language. there are many packages that allows to autocomplete various arguments to various utilities, shows help when you need it, can extract, show and complete arguments from 'configure' scripts and so on. signature.asc Description: PGP signature
Cross platform Development
Hello I read this page, but I still have questions : http://forum.dlang.org/thread/fzbaxwcrbztqedqgm...@forum.dlang.org#post-mailman.1142.1332716016.4860.digitalmars-d:40puremagic.com I also read this : http://stackoverflow.com/questions/1510989/can-c-be-compiled-into-platform-independent-code-why-not However, I am wondering what are the ways to develop in a native 64 bit linux machine, and deploy similar linux machines as well as in 64 + 32 bit windowes machines. Are there ways to do so? I will need some detailed guidance.
Re: sortUniq
On 23.01.15 19:13, Andrei Alexandrescu wrote:
On 1/23/15 10:05 AM, zeljkog wrote:
On 23.01.15 18:48, H. S. Teoh via Digitalmars-d wrote:
I think what he's trying to do is to call a function that returns a
delegate, and use that delegate to instantiate the filter template.
AFAIK I've never seen code like this before, and it looks like the
compiler isn't prepared to handle this.
Yes, I tried to use filter for unique, need closure.
I think there are many applications for this pattern.
Please post a complete snippet then. Thanks! -- Andrei
import std.stdio, std.algorithm;
auto unique(){
bool[int] c;
return (int a){
if (a in c)
return false;
else{
c[a] = true;
return true;
}
};
}
void main()
{
[1, 5, 5, 2, 1, 5, 6, 6].filter!(unique()).writeln;
}
Re: [WORK] groupBy is in! Next: aggregate
On Fri, Jan 23, 2015 at 10:29:13AM -0800, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jan 23, 2015 at 10:08:30AM -0800, Andrei Alexandrescu via
Digitalmars-d wrote:
[...]
The next step is to define an aggregate() function, which is a lot
similar to reduce() but works on ranges of ranges and aggregates a
function over each group. Continuing the previous example:
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.aggregate!max
.writeln;
should print:
[453, 600, 929, 812, 529, 768]
The aggregate function should support aggregating several functions
at once, e.g. aggregate!(min, max) etc.
[...]
Here's a working variadic implementation:
import std.algorithm.comparison : max, min;
import std.algorithm.iteration;
import std.stdio;
template aggregate(funcs...) {
auto aggregate(RoR)(RoR ror) {
return ror.map!(reduce!funcs);
}
}
void main() {
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.aggregate!(max,min)
.writeln;
}
Output (kinda ugly, but it works):
[Tuple!(int, int)(453, 293), Tuple!(int, int)(600, 600), Tuple!(int,
int)(929, 339), Tuple!(int, int)(812, 222), Tuple!(int, int)(529, 529),
Tuple!(int, int)(768, 768)]
Of course, it will require a little more polish before merging into
Phobos, but the core implementation is nowhere near the complexity of
groupBy.
T
--
The best compiler is between your ears. -- Michael Abrash
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 12:29:56 UTC, Kelly wrote: Hello Elie, This project looks great, thanks for the hard work. I downloaded Calypso and ldc2 about 6 hours ago to try your project out. I can get Calypso to compile with a couple small changes to assistbuilder.cpp (just adding a namespace qualifier for two class instantiations of CodeGen). That is with clang-3.5 from todays svn. Maybe a recent clang commit has changed things? Once I had a working Calypso ldc2 build, I unfortunately couldn't get the showcase example to build. I just use the build line from your git page to try to build, but I get an 'undefined identifier size_t' error. The pch file is produced properly but then this error comes up...it seems like while compiling druntime from the '-v' output?? Maybe something changed in the druntime submodule in the last few days...but I didn't really look into it yet. I hacked a couple things to just get around this error and then things fail because libshowcase.a isn't available. I assume that is a remnant from an earlier compilation technique, because it appears everything is self contained in the .o files being produced and then linked on the command line...so I just thought I would let you know this part doesn't work. If you could give me a hint on the 'undefined identifier size_t' error, I can look into it a bit further here...I am just getting tired and probably not seeing what is going on there. If you are on #ldc I will be on there later today. Not sure what your username is in #ldc. At least one other person has been by asking if you were there also :) Thanks, Kelly (wilsonk-laptop) Thanks for the feedback Kelly, you're probably the first person to give it a serious try, sorry for the bumpy ride :) Since I was focused on getting Ogre working and neither rebuilt druntime/phobos nor tested the showcase example against the latest commits they might have broken something. Also the README forgets to say how libshowcase.a should be built: clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d Adding this now. I'm going to fix the rest this afternoon (finally some free time), and also figure out why assistbuilder.cpp failed to compile against the latest Clang 3.5. Also going to setup a testing script to ensure not everything gets broken again by a commit.
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 Fri, Jan 23, 2015 at 05:34:28PM +, aldanor via Digitalmars-d wrote: 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. That's not a problem; post your ideas / drafts here and I'm sure you'll get lots of feedback and improvement suggestions. 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. 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. [...] 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. I vote for ddoc / static generation. The site itself is static anyway, using client-side JS to do this seems to be overkill. 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 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. T -- Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.
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: Compile time iota
On 1/23/15 7:21 AM, Dicebot wrote: So, to put it clear : do you approve merging https://github.com/D-Programming-Language/phobos/pull/2687 in general? (without any details about actual std.meta module layout etc). Assuming that old std.typetuple will be kept deprecated and (eventually) hidden from docs without removal for a very long time of course. I made a pass through the entire document and discussion and it seems to need a few improvements before being pulled. The main issues I see are (a) the names changed from a confusing word to a confusing idiom; (b) the Pack template, probably the one thing that could add value to the establishment, is private. So in the bad old times we had this confusing name Typelist in std.typelist and some okay/meh names like staticMap and staticIndexOf. With the new coolness std.typelist.Typelist is std.meta.list.List. That is confusing if used standalone as List after importing std.meta.list and a good mouthful to use with full qualification, so the following idiom is proposed: import meta = std.meta.list; This doesn't sound good. If one is in the need for some list-specific stuff, how come they have to import std.meta.list and then call it meta? Does one ever use import container = std.container.array? Also there's only std.meta.list and no other std.meta.xxx. Is there a plan there? Why not use packages etc? Just define TemplateList and TemplatePack in std.meta and call it a day. Andrei
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 10:02:55 UTC, Jacob Carlborg wrote: Could this work for Objective-C as well. I'm working on adding support for Objective-C to DMD [1]. [1] https://github.com/D-Programming-Language/dmd/pull/4321 It's planned to add Objective-C to Calypso, although I never used it and know little about it. Would you be interested in implementing support for its different flavors in Calypso, Jacob? You'd be welcome to the team :-)
Re: sortUniq
On 1/23/15 10:05 AM, zeljkog wrote: On 23.01.15 18:48, H. S. Teoh via Digitalmars-d wrote: I think what he's trying to do is to call a function that returns a delegate, and use that delegate to instantiate the filter template. AFAIK I've never seen code like this before, and it looks like the compiler isn't prepared to handle this. Yes, I tried to use filter for unique, need closure. I think there are many applications for this pattern. Please post a complete snippet then. Thanks! -- Andrei
Re: sortUniq
On 1/23/15 7:04 AM, zeljkog wrote: On 22.01.15 22:40, Andrei Alexandrescu wrote: There's this classic patter on Unix: |sort|uniq, i.e. sort some data and only display the unique elements. Loosely-related, compiling ... auto ret = arr.filter!(myFilter()); ... I got: Error: closures are not yet supported in CTFE Using struct with opCall directly also does not pass. Did I miss something? Is it near? Must be you put that code at top level and the compiler tried to interpret it during compilation. -- Andrei
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
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
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On 1/23/15 10:09 AM, aldanor wrote: 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? Both are nice: http://tour.golang.org/welcome/1 http://rustbyexample.com/ /* 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! */ I can get cranked on that. Just give me the ddoc macros to fill. Andrei
Re: [WORK] groupBy is in! Next: aggregate
On Fri, 23 Jan 2015 10:08:30 -0800, Andrei Alexandrescu wrote: So H.S. Teoh awesomely took https://github.com/D-Programming-Language/phobos/pull/2878 to completion. We now have a working and fast relational group by facility. This is great news. It seems like every time I make use of component programming, I need groupBy at least once. I have a D file with an old copy of a groupBy implementation (I think it's Andrei's original stab at it) and it gets copied around to the various projects.
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
Dne 23.1.2015 v 19:16 Andrei Alexandrescu via Digitalmars-d napsal(a): Both are nice: http://tour.golang.org/welcome/1 http://rustbyexample.com/ Or something along the lines of https://tryhaskell.org With possible integration with D REPL. smime.p7s Description: Elektronicky podpis S/MIME
Re: Calypso and the future of D
On 2015-01-23 17:02, Andrei Alexandrescu wrote: We should make the life of plugin writers easy. They do get to decide what other prerequisites their tools have. Are you suggesting to have a general plugin architecture in DMD? That would be very cool, especially if they can be installed as Dub packages. Although I'm guessing there will be complains that it might create different flavors of D. And how will multiple plugins interact with each other? -- /Jacob Carlborg
Re: Speeding up compilation by using jemalloc
On Thursday, 22 January 2015 at 19:37:11 UTC, weaselcat wrote: Might be of use to someone, but I was looking for ways to speed up dmd's albeit already fast compilation times. Just by dropping in jemalloc in place of glibc's malloc via LD_PRELOAD on my linux machine I saw a 10-15% drop in compilation times across the board. Not sure if this is common knowledge or not. Might be interesting to try some other implementations, too? TCMalloc[0] and nedmalloc[1] at least have permissive licenses. (Hoard[2] and Lockless[3] also seem interesting, but are GPL or worse.) -Wyatt [0] Part of gperf-tools https://code.google.com/p/gperftools/ [1] http://www.nedprod.com/programs/portable/nedmalloc/index.html [2] http://www.hoard.org/ [3] http://locklessinc.com/downloads/
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Fri, Jan 23, 2015 at 05:03:15PM +, aldanor via Digitalmars-d wrote: [...] 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. Our current documentation is *reference* documentation, i.e., something you look stuff up in *after* you've learned the language. It's not suitable for a tutorial or getting-started guide. We need more of those! 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. 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).) 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. Yeah I've run into the same problem. Google search does not eliminate the need for a proper, well-thought-out, navigable index. 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). Actually, this has annoyed me so much that I've completely nuked the page in Phobos git HEAD, and replaced it with something hopefully more useful. You can see this new page under the prerelease tab: http://dlang.org/phobos-prerelease/index.html So hopefully, by the next release, we will no longer be plagued by complaints about the current leading page. 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). I'm thinking perhaps an autogenerated alphabetical index of all symbols might be in order here? 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. 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. 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. If you're not happy with Ali's book, please contribute your own. I'm pretty sure the dlang.org maintainers will be
Re: dlang.org redesign -- general thoughts and issues [part 1]
On Friday, 23 January 2015 at 10:31:45 UTC, aldanor wrote: Hi all, I've started redesigning dlang.org AGAIN (yea, I know...). 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. My own thought: http://forum.dlang.org/post/pywtsfqqrqigxynfa...@forum.dlang.org 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.
Re: [WORK] groupBy is in! Next: aggregate
On Fri, Jan 23, 2015 at 10:08:30AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
So H.S. Teoh awesomely took
https://github.com/D-Programming-Language/phobos/pull/2878 to
completion. We now have a working and fast relational group by
facility.
Unfortunately it doesn't work in pure/@safe/nothrow code because of
limitations in the current RefCounted implementation.
[...]
The next step is to define an aggregate() function, which is a lot
similar to reduce() but works on ranges of ranges and aggregates a
function over each group. Continuing the previous example:
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.aggregate!max
.writeln;
should print:
[453, 600, 929, 812, 529, 768]
The aggregate function should support aggregating several functions at
once, e.g. aggregate!(min, max) etc.
Takers?
[...]
Isn't that just a simple matter of defining aggregate() in terms of
map() and reduce()? Working example:
import std.algorithm.comparison : max;
import std.algorithm.iteration;
import std.stdio;
auto aggregate(alias func, RoR)(RoR ror) {
return ror.map!(reduce!func);
}
void main() {
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.aggregate!max
.writeln;
}
Output is as expected.
T
--
Verbing weirds language. -- Calvin ( Hobbes)
Re: sortUniq
On Fri, Jan 23, 2015 at 09:40:42AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 1/23/15 7:04 AM, zeljkog wrote: On 22.01.15 22:40, Andrei Alexandrescu wrote: There's this classic patter on Unix: |sort|uniq, i.e. sort some data and only display the unique elements. Loosely-related, compiling ... auto ret = arr.filter!(myFilter()); ... I got: Error: closures are not yet supported in CTFE Using struct with opCall directly also does not pass. Did I miss something? Is it near? Must be you put that code at top level and the compiler tried to interpret it during compilation. -- Andrei I think what he's trying to do is to call a function that returns a delegate, and use that delegate to instantiate the filter template. AFAIK I've never seen code like this before, and it looks like the compiler isn't prepared to handle this. T -- I am not young enough to know everything. -- Oscar Wilde
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: Speeding up compilation by using jemalloc
On 1/23/15 8:59 AM, Wyatt wrote: On Thursday, 22 January 2015 at 19:37:11 UTC, weaselcat wrote: Might be of use to someone, but I was looking for ways to speed up dmd's albeit already fast compilation times. Just by dropping in jemalloc in place of glibc's malloc via LD_PRELOAD on my linux machine I saw a 10-15% drop in compilation times across the board. Not sure if this is common knowledge or not. Might be interesting to try some other implementations, too? TCMalloc[0] and nedmalloc[1] at least have permissive licenses. (Hoard[2] and Lockless[3] also seem interesting, but are GPL or worse.) -Wyatt [0] Part of gperf-tools https://code.google.com/p/gperftools/ [1] http://www.nedprod.com/programs/portable/nedmalloc/index.html [2] http://www.hoard.org/ [3] http://locklessinc.com/downloads/ Definitely measurements should help. From the many measurements we've run at Facebook, jemalloc would be overall a good bet. Also I work with Jason Evans so if there are issues we want improved I might ask him :o). -- Andrei
Re: Calypso and the future of D
On 1/23/15 8:57 AM, Jacob Carlborg wrote: On 2015-01-23 17:02, Andrei Alexandrescu wrote: We should make the life of plugin writers easy. They do get to decide what other prerequisites their tools have. Are you suggesting to have a general plugin architecture in DMD? It's something worth thinking about. That would be very cool, especially if they can be installed as Dub packages. Although I'm guessing there will be complains that it might create different flavors of D. And how will multiple plugins interact with each other? As of now I'm unclear on the details. Supporting plugins seems to be an interesting recent trend in compilers. Andrei
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: sortUniq
On 23.01.15 18:48, H. S. Teoh via Digitalmars-d wrote: I think what he's trying to do is to call a function that returns a delegate, and use that delegate to instantiate the filter template. AFAIK I've never seen code like this before, and it looks like the compiler isn't prepared to handle this. Yes, I tried to use filter for unique, need closure. I think there are many applications for this pattern.
[WORK] groupBy is in! Next: aggregate
So H.S. Teoh awesomely took
https://github.com/D-Programming-Language/phobos/pull/2878 to
completion. We now have a working and fast relational group by facility.
See it at work!
#!/usr/bin/rdmd
void main()
{
import std.algorithm, std.stdio;
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.writeln;
}
[[293, 453], [600], [929, 339], [812, 222, 680], [529], [768]]
The next step is to define an aggregate() function, which is a lot
similar to reduce() but works on ranges of ranges and aggregates a
function over each group. Continuing the previous example:
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.aggregate!max
.writeln;
should print:
[453, 600, 929, 812, 529, 768]
The aggregate function should support aggregating several functions at
once, e.g. aggregate!(min, max) etc.
Takers?
Andrei
Re: Calypso: Direct and full interfacing to C++
Hello Elie, Just a little build script until cmake can be used properly: #!/bin/bash set -x clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o /bin/rm calypso_cache* ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d I remove the the calypso_cache otherwise there will be an error if a previous build failed and the C++ files get modified. It looks like the 'undefined identifier size_t;' error is just from testStruct. If I comment out all refs/uses to testStruct then things compile and run fine. Good stuff. Thanks, Kelly P.S. If I find a little time, I'll try to get up to speed on the code base :) On Friday, 23 January 2015 at 17:18:22 UTC, Elie Morisse wrote: Thanks for the feedback Kelly, you're probably the first person to give it a serious try, sorry for the bumpy ride :) Since I was focused on getting Ogre working and neither rebuilt druntime/phobos nor tested the showcase example against the latest commits they might have broken something. Also the README forgets to say how libshowcase.a should be built: clang++ -std=c++11 -c showcase.cpp -o showcase.cpp.o ar rcs libshowcase.a showcase.cpp.o ldc2 -cpp-args -std=c++11 -Llibshowcase.a -L-lstdc++ showcase.d Adding this now. I'm going to fix the rest this afternoon (finally some free time), and also figure out why assistbuilder.cpp failed to compile against the latest Clang 3.5. Also going to setup a testing script to ensure not everything gets broken again by a commit.
Re: Calypso and the future of D
On Friday, 23 January 2015 at 00:24:45 UTC, Andrei Alexandrescu wrote: I think it's important that we enable Calypso (https://github.com/Syniurge/Calypso) and related tooling that interfaces D with other languages, notably C++. A key topic in 2015 for D is playing well with C++. A good C++ interface will give access to a host of mature C++ libraries, starting of course with the C++ standard library. More importantly, it will provide a smooth migration path for organizations that want to do development in D whilst taking advantage of their legacy code. I'd like to open the topic of what can we do in core D to make Calypso better. But first, I want to get better acquainted with Calypso and raise awareness of it with coworkers and the larger community. To my dismay, the github homepage provides exactly zero look and feel use examples beyond the mechanics of building Calypso itself. To Calypso's creator: is it possible to beef up the documentation of Calypso with a few use cases? Ideally there'd be a soup-to-nuts step by step guide of making a C++ library (either artificial or extant) interfacing with D. Also: what things on the D side would be necessary to make the interface better? Exceptions would be an obvious topic on which we have an attack already (more on it later). Andrei thanks for finally sharing your thoughts on the matter :-) I'll see what I can do this week-end to expand examples and write a tutorial. As for what could be done in core D, I haven't struck anything blocking while writing Calypso. Exception catching is next after the first light of my Ogre3D demo, Clang will probably simplify handling of C++ exceptions a lot.
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Fri, Jan 23, 2015 at 06:30:04PM +, aldanor via Digitalmars-d wrote: On Friday, 23 January 2015 at 18:17:30 UTC, H. S. Teoh wrote: [...] 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. I wouldn't mind just generating a static index and putting it on an index page somewhere. I'm not against using JS for stuff like this, but generally I prefer static navigation. (But that's just me. I know I'm in the minority. :-P) [...] 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!) It's not that hard. Just start submitting PRs and pointing people to it. Make enough noise about it and people are bound to notice. If your idea has any merit (and I think it does) people should follow suit. 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). Of course it can be fixed -- what *can't* programmers fix? (Besides the halting problem, that is. :-P) It's just a matter of someone stepping up to the plate and actually *doing* something about it. Besides, Andrei has even offered to write the content -- you have preapproval even before you ask for it! If I were you, I'd charge full steam ahead! T -- The easy way is the wrong way, and the hard way is the stupid way. Pick one.
Re: This Week in D, issue 2
On 19-Jan-2015 20:05, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jan-18.html http://www.reddit.com/r/programming/comments/2sy7lg/this_week_in_d_january_18_2015/ For those of you who saw the draft earlier, hit refresh to ensure you aren't seeing a cached version. RSS feed: http://arsdnet.net/this-week-in-d/twid.rss This week, we got new web style thanks to the folks in the other forum. Tech speaking, it now serves gzipped files as a test of what I want to see about putting on dlang.org too. Email list will be coming next week and hopefully a move to dlang.org too. Fixed a few bugs in my stats gathering too, hopefully we'll have all the kinks worked out and on-time release next week! Falsey values may include any struct with opCast(T:bool) or somehow indicate that it's going to be attempted, afterall this is common D idiom. -- Dmitry Olshansky
Re: [WORK] groupBy is in! Next: aggregate
On 1/23/15 10:29 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jan 23, 2015 at 10:08:30AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
So H.S. Teoh awesomely took
https://github.com/D-Programming-Language/phobos/pull/2878 to
completion. We now have a working and fast relational group by
facility.
Unfortunately it doesn't work in pure/@safe/nothrow code because of
limitations in the current RefCounted implementation.
[...]
The next step is to define an aggregate() function, which is a lot
similar to reduce() but works on ranges of ranges and aggregates a
function over each group. Continuing the previous example:
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.aggregate!max
.writeln;
should print:
[453, 600, 929, 812, 529, 768]
The aggregate function should support aggregating several functions at
once, e.g. aggregate!(min, max) etc.
Takers?
[...]
Isn't that just a simple matter of defining aggregate() in terms of
map() and reduce()? Working example:
import std.algorithm.comparison : max;
import std.algorithm.iteration;
import std.stdio;
auto aggregate(alias func, RoR)(RoR ror) {
return ror.map!(reduce!func);
}
void main() {
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.aggregate!max
.writeln;
}
Output is as expected.
Clever! Or, conversely, I'm not that bright! Yes, this is awesome.
Probably the actual name aggregate should be defined even with that
trivial implementation to help folks like me :o). -- Andrei
Re: [WORK] groupBy is in! Next: aggregate
On 1/23/15 10:34 AM, H. S. Teoh via Digitalmars-d wrote: Of course, it will require a little more polish before merging into Phobos, but the core implementation is nowhere near the complexity of groupBy. open https://github.com/D-Programming-Language/phobos/pulls [F5]... [F5]... [F5]... Andrei
Re: dlang.org redesign -- general thoughts and issues [part 1]
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.
[Issue 13870] [ICE] shared or immutable types can not be mapped to C++ (immutable(char))
https://issues.dlang.org/show_bug.cgi?id=13870 Guillaume Chatelet chatelet.guilla...@gmail.com changed: What|Removed |Added Keywords|C++ |ice --
[Issue 13870] [ICE] shared or immutable types can not be mapped to C++ (immutable(char))
https://issues.dlang.org/show_bug.cgi?id=13870 Guillaume Chatelet chatelet.guilla...@gmail.com changed: What|Removed |Added Keywords|ice |C++ CC||chatelet.guilla...@gmail.co ||m --
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: Speeding up compilation by using jemalloc
On Friday, 23 January 2015 at 16:59:41 UTC, Wyatt wrote: On Thursday, 22 January 2015 at 19:37:11 UTC, weaselcat wrote: Might be of use to someone, but I was looking for ways to speed up dmd's albeit already fast compilation times. Just by dropping in jemalloc in place of glibc's malloc via LD_PRELOAD on my linux machine I saw a 10-15% drop in compilation times across the board. Not sure if this is common knowledge or not. Might be interesting to try some other implementations, too? TCMalloc[0] and nedmalloc[1] at least have permissive licenses. (Hoard[2] and Lockless[3] also seem interesting, but are GPL or worse.) -Wyatt [0] Part of gperf-tools https://code.google.com/p/gperftools/ [1] http://www.nedprod.com/programs/portable/nedmalloc/index.html [2] http://www.hoard.org/ [3] http://locklessinc.com/downloads/ Hi, I actually did try tcmalloc and I can't remember if it performed better than malloc or not, but it performed overall worse than jemalloc. I'm assuming because it's(as the name impllies), optimized for heavily threaded scenarios which DMD is not. I didn't try the others because they're not readily available in my package manager.
Re: std.experimental.logger formal review round 3
On 1/6/15 8:51 AM, Robert burner Schadek wrote: recent updates: * Martins CT log function disabling (thanks Martin) * new thread local indirection Logger between free standing log functions and program global Logger * more documentation * some @trusted have been remove (thanks Dicebot) * local imports please review I propose we pull this in today and make it available for 2.067 as std.experimental.logger. We've been through a number of iterations with this and the best way to move forward is to accumulate a bit of real-world experience with it. Since we're deploying to std.experimental there is understanding breaking changes are still possible. Dicebot, as the review manager you get to decide. What do you say? Andrei
Re: Cross platform Development
On Friday, 23 January 2015 at 17:32:09 UTC, seany wrote: Hello I read this page, but I still have questions : http://forum.dlang.org/thread/fzbaxwcrbztqedqgm...@forum.dlang.org#post-mailman.1142.1332716016.4860.digitalmars-d:40puremagic.com I also read this : http://stackoverflow.com/questions/1510989/can-c-be-compiled-into-platform-independent-code-why-not However, I am wondering what are the ways to develop in a native 64 bit linux machine, and deploy similar linux machines as well as in 64 + 32 bit windowes machines. Are there ways to do so? I will need some detailed guidance. I think you need to ask a more detailed question. Do you want source compatibility or binary compatibility? Are you using GUI stuff? Cuz that's gonna add a world of hurt. Are you wanting to take a bit of source, compile it, and have that single executable run on all 32/64/linux/windows machines? If this is what you want, I'd recommend perl. One bit of code ... runs everywhere! -Andy
Re: Calypso and the future of D
On 1/23/15 10:27 AM, Elie Morisse wrote:
Exception catching is next after the first light of my Ogre3D demo,
Clang will probably simplify handling of C++ exceptions a lot.
On that front, a coworker gave me a simple idea for integration.
1. All C++ non-polymorphic types thrown cannot be caught in D
2. We (or Calypso) define D class counterparts for polymorphic types
thrown from C++, notably std::exception and subtypes. N.B. those are D
classes, not D structs
3. D code can catch std::exception. The only caveat is that the caught
exception cannot survive the catch statement. Given that calling into
C++ is not the paramount of safety in the first place, I'd say that's a
reasonable compromise.
Example:
import core.stdcpp.vector;
import core.stdcpp.exception;
core.stdcpp.exception g;
void fun(core.stdcpp.vector!int v)
{
try
{
v.push_back(42);
}
catch (core.stdcpp.exception e) // fine, can catch
{
g = e; // ouch, will dangle
}
}
Thoughts?
Andrei
Re: [WORK] groupBy is in! Next: aggregate
On Fri, Jan 23, 2015 at 10:47:28AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 1/23/15 10:34 AM, H. S. Teoh via Digitalmars-d wrote:
Of course, it will require a little more polish before merging into
Phobos, but the core implementation is nowhere near the complexity of
groupBy.
open https://github.com/D-Programming-Language/phobos/pulls
[F5]... [F5]... [F5]...
[...]
void main() {
foreach (iota(0 .. 60 * 60 * F5sPerSecond))
writeln([F5]...);
writeln(qENDMSG
https://github.com/D-Programming-Language/phobos/pull/2899
ENDMG);
}
;-)
T
--
No! I'm not in denial!
[Issue 13337] Invalid extern C++ namespace resolution
https://issues.dlang.org/show_bug.cgi?id=13337 Guillaume Chatelet chatelet.guilla...@gmail.com changed: What|Removed |Added Keywords||C++ --
[Issue 13867] Overriding a method from an extern(C++) interface requires extern(C++) on the method definition
https://issues.dlang.org/show_bug.cgi?id=13867 Guillaume Chatelet chatelet.guilla...@gmail.com changed: What|Removed |Added Keywords||C++ CC||chatelet.guilla...@gmail.co ||m --
Re: I'll be presenting at NWCPP on Jan 21 at Microsoft
On Friday, 23 January 2015 at 05:54:41 UTC, Walter Bright wrote: On 1/22/2015 12:52 PM, Gary Willoughby wrote: Me too, is there any video available? https://www.youtube.com/watch?v=IkwaV6k6BmM I can't bear to watch it, you'll have to do it for me! My right ear can't hear too! :) Matheus.
Re: [WORK] groupBy is in! Next: aggregate
On 1/23/15 3:08 PM, Andrei Alexandrescu wrote:
So H.S. Teoh awesomely took
https://github.com/D-Programming-Language/phobos/pull/2878 to
completion. We now have a working and fast relational group by facility.
See it at work!
#!/usr/bin/rdmd
void main()
{
import std.algorithm, std.stdio;
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.writeln;
}
[[293, 453], [600], [929, 339], [812, 222, 680], [529], [768]]
The next step is to define an aggregate() function, which is a lot
similar to reduce() but works on ranges of ranges and aggregates a
function over each group. Continuing the previous example:
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.aggregate!max
.writeln;
should print:
[453, 600, 929, 812, 529, 768]
The aggregate function should support aggregating several functions at
once, e.g. aggregate!(min, max) etc.
Takers?
Andrei
In most languages group by yields a tuple of {group key, group values}.
For example (Ruby or Crystal):
a = [1, 4, 2, 4, 5, 2, 3, 7, 9]
groups = a.group_by { |x| x % 3 }
puts groups #= {1 = [1, 4, 4, 7], 2 = [2, 5, 2], 0 = [3, 9]}
In C# it's also called group by: http://www.dotnetperls.com/groupby
Java:
http://docs.oracle.com/javase/8/docs/api/java/util/stream/Collectors.html#groupingBy-java.util.function.Function-
SQL: http://www.w3schools.com/sql/sql_groupby.asp
So I'm not sure groupBy is a good name for this.
Re: Calypso and the future of D
On 2015-01-23 19:43, Andrei Alexandrescu wrote:
On that front, a coworker gave me a simple idea for integration.
1. All C++ non-polymorphic types thrown cannot be caught in D
2. We (or Calypso) define D class counterparts for polymorphic types
thrown from C++, notably std::exception and subtypes. N.B. those are D
classes, not D structs
3. D code can catch std::exception. The only caveat is that the caught
exception cannot survive the catch statement. Given that calling into
C++ is not the paramount of safety in the first place, I'd say that's a
reasonable compromise.
Example:
import core.stdcpp.vector;
import core.stdcpp.exception;
core.stdcpp.exception g;
void fun(core.stdcpp.vector!int v)
{
try
{
v.push_back(42);
}
catch (core.stdcpp.exception e) // fine, can catch
{
g = e; // ouch, will dangle
}
}
Thoughts?
Even with these restrictions C++ exceptions are quite complicated. I've
probably said this before but in 64bit Objective-C (which uses the same
exception model as C++) you can only catch C++ exceptions with the
catch-all block which won't let you access the actual exception:
@try {
v.push_back(42);
}
@catch (...) { }
Not sure if that makes it particular easier to implement.
--
/Jacob Carlborg
Re: [WORK] groupBy is in! Next: aggregate
On Friday, 23 January 2015 at 18:47:29 UTC, Andrei Alexandrescu wrote: open https://github.com/D-Programming-Language/phobos/pulls [F5]... [F5]... [F5]... Andrei Haha, that's funny!
Re: [WORK] groupBy is in! Next: aggregate
On 1/23/15 12:38 PM, bearophile wrote:
Ary Borenszweig:
In most languages group by yields a tuple of {group key, group values}.
I'm saying this since some years... (and those languages probably don't
use sorting to perform the aggregation).
At some point in the coming years the pain is bound to become unbearable
so you'll give the gift of a pull request. -- Andrei
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 This is as per spec :)
Re: [WORK] groupBy is in! Next: aggregate
On Friday, 23 January 2015 at 20:19:31 UTC, Ary Borenszweig wrote:
On 1/23/15 3:08 PM, Andrei Alexandrescu wrote:
So H.S. Teoh awesomely took
https://github.com/D-Programming-Language/phobos/pull/2878 to
completion. We now have a working and fast relational group
by facility.
See it at work!
#!/usr/bin/rdmd
void main()
{
import std.algorithm, std.stdio;
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.writeln;
}
[[293, 453], [600], [929, 339], [812, 222, 680], [529], [768]]
The next step is to define an aggregate() function, which is a
lot
similar to reduce() but works on ranges of ranges and
aggregates a
function over each group. Continuing the previous example:
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.aggregate!max
.writeln;
should print:
[453, 600, 929, 812, 529, 768]
The aggregate function should support aggregating several
functions at
once, e.g. aggregate!(min, max) etc.
Takers?
Andrei
In most languages group by yields a tuple of {group key, group
values}.
For example (Ruby or Crystal):
a = [1, 4, 2, 4, 5, 2, 3, 7, 9]
groups = a.group_by { |x| x % 3 }
puts groups #= {1 = [1, 4, 4, 7], 2 = [2, 5, 2], 0 = [3, 9]}
In C# it's also called group by:
http://www.dotnetperls.com/groupby
Java:
http://docs.oracle.com/javase/8/docs/api/java/util/stream/Collectors.html#groupingBy-java.util.function.Function-
SQL: http://www.w3schools.com/sql/sql_groupby.asp
So I'm not sure groupBy is a good name for this.
You are talking about two different functions here. group by and
partition by. The function that has been implemented is often
called partition by.
The best example I know of:
https://clojuredocs.org/clojure.core/group-by
https://clojuredocs.org/clojure.core/partition-by
Re: Calypso: Direct and full interfacing to C++
On 2015-01-23 18:56, Elie Morisse wrote: It's planned to add Objective-C to Calypso, although I never used it and know little about it. Would you be interested in implementing support for its different flavors in Calypso, Jacob? You'd be welcome to the team :-) For the time being I think I need to focus on getting the Objective-C support implemented in DMD. But after that, we'll see. -- /Jacob Carlborg
DLang Silicon Valley First Meetup
Hi folks, Yesterday's first DLang/Silicon Valley Meetup was really nice. We've had three talks (even I talked in spite of having a really hoarse voice following a cold) and we've made a number of important plans and decisions going forward. Vic Cekvenich, the initiator of the meetup, was ousted following political infighting and replaced by Ali Çehreli. I'm kidding - but only partially! Vic is the busy CEO of http://apakau.com (btw: they're hiring) and he wanted someone else to take the operations of the meetup. Ali graciously accepted the role. Vic will continue providing venue for the meetups, which is no small feat - the room we were in today would ordinarily rent for $2000. Vic used his karma with http://sv.tie.org to get the room for free. (Aside from the fact it could have doubled for a fridge, the venue was really nice.) Many thanks to Vic and TiE! BTW Vic is a great guy to talk to. He has that uncanny ability of entrepreneurs to move things forward with each sentence he utters. A good contrast with the Infinite Bickering(tm) that seems to be sometimes going on in our forums. Vic provided a few very interesting high-level ideas for D that we plan to bring up for review soon. Anyhow, the long and short of it is we've started with the right foot with DLang/Silicon Valley. We're waiting for the president to state the frequency and usual meeting days and times, etc. If you're in the area, join us! Stay tuned for more announcements. Andrei
Re: [WORK] groupBy is in! Next: aggregate
On 1/23/15 12:19 PM, Ary Borenszweig wrote:
In most languages group by yields a tuple of {group key, group values}.
Interesting, thanks. Looks like we're at a net loss of information with
our current approach.
@quickfur, do you think you could expose a tuple with key and
values? The former would be the function value, the latter would be
what we offer right now.
That would apply only to the unary version of groupBy.
Andrei
Re: [WORK] groupBy is in! Next: aggregate
Ary Borenszweig:
In most languages group by yields a tuple of {group key, group
values}.
I'm saying this since some years... (and those languages probably
don't use sorting to perform the aggregation).
Bye,
bearophile
Re: forcing @nogc on class destructors
On 1/23/15 3:40 PM, deadalnix wrote: 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. This is as per spec :) No, spec says your dtor is not guaranteed to run for unreferenced memory. It doesn't say your destructor may not be run even when the memory is collected. In fact, it says The garbage collector calls the destructor function when the object is deleted. But my real point is that depending on dtors being called by the GC is not broken 90% of the time. -Steve
Re: [WORK] groupBy is in! Next: aggregate
On Fri, Jan 23, 2015 at 12:40:01PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 1/23/15 12:38 PM, bearophile wrote:
Ary Borenszweig:
In most languages group by yields a tuple of {group key, group
values}.
I'm saying this since some years... (and those languages probably
don't use sorting to perform the aggregation).
At some point in the coming years the pain is bound to become
unbearable so you'll give the gift of a pull request. -- Andrei
(!!!)
*cowers and hides from the rotten tomatoes...*
T
--
It won't be covered in the book. The source code has to be useful for
something, after all. -- Larry Wall
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Fri, Jan 23, 2015 at 09:20:10PM +, Zach the Mystic via Digitalmars-d wrote: [...] I have a basic suggestion on how to get started. Create a Learning D button and put it on the menu at left on the front page. On the page it links to, start by researching and listing every existing resource for learning D, in a kitchen sink kind of way. Now future contributors can know what already exists, and what doesn't. The importance of this list is that anyone wanting to help create new teaching aids can quickly get up to speed on the current state of affairs. They can feel assured that they're not duplicating anyone else's work. As the official list and accessible from the front page, it's more likely to be kept up to date. The point is that it serves double duty both as a treasure trove of learning links, and as a complete reference for future contributors. Destroy, please! Let's see the PR! ;-) T -- Democracy: The triumph of popularity over principle. -- C.Bond
Re: [WORK] groupBy is in! Next: aggregate
On Fri, Jan 23, 2015 at 09:56:11PM +, MattCoder via Digitalmars-d wrote:
On Friday, 23 January 2015 at 18:08:30 UTC, Andrei Alexandrescu wrote:
So H.S. Teoh awesomely took
https://github.com/D-Programming-Language/phobos/pull/2878 to
completion. We now have a working and fast relational group by
facility.
See it at work!
#!/usr/bin/rdmd
void main()
{
import std.algorithm, std.stdio;
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.writeln;
}
[[293, 453], [600], [929, 339], [812, 222, 680], [529], [768]]
Sorry if this a dumb question, but since you're grouping an array
according some rule, this shouldn't be:
[293, 453, 929, 339, 529][600, 812, 222, 680, 768]
?
Because then you have the array of trues and falses according the
condition (a 1).
[...]
It's kind of a misnomer, because it actually only considers *consecutive
runs* of equivalent elements; it doesn't look at the whole range before
deciding what goes in which group. So technically it should be called
consecutiveGroupBy or consecutivePartitionBy, but that's too big a
mouthful to be a usable name.
What you describe could be an interesting candidate to add, though. It
could iterate over distinct values of the predicate, and traverse the
forward range (input ranges obviously can't work unless you allocate,
which makes it no longer lazy) each time. This, however, has O(n*k)
complexity where k is the number of distinct predicate values. If it's
anything bigger than bool or a relatively small enum, it would be
impractical. Moreover, the requirement to traverse the range multiple
times kinda sux; you might as well just call filter() with different
expected values yourself, in a loop. In fact, you could ostensibly
implement it something along these lines:
auto globalPartition(alias pred, R)(R range) {
alias Values = typeof(pred(range.front, range.front));
return iota(Values.min, Values.max)
.map!(v = range.save.filter!(pred(e) == v));
}
T
--
Who told you to swim in Crocodile Lake without life insurance??
Re: [WORK] groupBy is in! Next: aggregate
On Fri, Jan 23, 2015 at 08:44:05PM +, via Digitalmars-d wrote: [...] You are talking about two different functions here. group by and partition by. The function that has been implemented is often called partition by. [...] It's not too late to rename it, since we haven't released it yet. We still have a little window of time to make this change if necessary. Andrei? Returning each group as a tuple sounds like a distinct, albeit related, function. It can probably be added separately. T -- Why waste time reinventing the wheel, when you could be reinventing the engine? -- Damian Conway
Re: [WORK] groupBy is in! Next: aggregate
On Friday, 23 January 2015 at 18:08:30 UTC, Andrei Alexandrescu
wrote:
So H.S. Teoh awesomely took
https://github.com/D-Programming-Language/phobos/pull/2878 to
completion. We now have a working and fast relational group
by facility.
See it at work!
#!/usr/bin/rdmd
void main()
{
import std.algorithm, std.stdio;
[293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
.groupBy!(a = a 1)
.writeln;
}
[[293, 453], [600], [929, 339], [812, 222, 680], [529], [768]]
Sorry if this a dumb question, but since you're grouping an array
according some rule, this shouldn't be:
[293, 453, 929, 339, 529][600, 812, 222, 680, 768]
?
Because then you have the array of trues and falses according
the condition (a 1).
Matheus.
Re: dlang.org redesign -- general thoughts and issues [part 1]
On Friday, 23 January 2015 at 19:20:11 UTC, aldanor wrote: 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 :) Although I like the new look overall, there are a few things on the docs for the standard library that aren't the best they could be. Currently a jump-to list is generated for all elements with children, regardless of the number of them. I believe that no jump list (apart from the one to navigate the entire page) should be shown if there are 2 items or less, because the user can already see the entire content that would be linked to. Now on to the positioning of the jump links themselves. Currently they are positioned above the declaration of the element who's children it jumps to. I believe that the jump links should instead be in the body of the element, after the description, but immediately before any children. Children with overloads (http://dlang.org/phobos/std_socket.html#.SocketOSException.this) don't currently merge like the they do at the top-most level. Enums should probably be formatted differently from normal types, with a table of it's members rather than a list, as enum member descriptions tend to be more minimal. Parhaps use a table-view when there is only one line for the description of every member of the enum, and the current list view otherwise?
Re: What to do with InvalidMemoryOperationError
On Friday, 23 January 2015 at 21:25:01 UTC, Nordlöw wrote: On Friday, 23 January 2015 at 10:13:43 UTC, Joakim wrote: InvalidMemoryOperationError generally means that you are performing certain disallowed memory operations during a full garbage collection, such as allocating while the gc is running. If my app is single-threaded this cannot happen then. Single-/multi-threaded doesn't make a difference. This happens with a single thread, too. The GC calls destructors. When a destructor allocates then, it allocates during a GC run.
Re: Calypso: Direct and full interfacing to C++
Hello Elie, The small patch for defining size_t works here. Thanks. I just wanted to let people know that showcase.d should build fine (one deprecation warning, but not a big deal). People might still need the small quick fixes for gen/cpp/assistbuilder.cpp, but just adding clang:: in a couple spots shouldn't be too arduous for anybody if they really want to compile and play with Calypso. Thanks, Kelly
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: 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 best/finalized bits and examples into a sort of a D by Example official section on the website. Wiki is useful as a collaborative sandbox or a staging area, but it's fugly, feels foreign and not so nice for reading. ... that's all. At this point the disgruntled newbie closes the dlang.org website and goes on learning himself some Rust. [NB] SUGGESTION: initiate work on an Official Guide and keep it up to date with the latest language features. It could even be largely a copy-paste from Ali's book and TDPL (upon Ali's and Andrei's permission), omitting unnecessary details (and rather pointing at a specific places in documentation where additional information could be found) and written in a friendly manner with a human touch. I think it's much simpler than it sounds if we do it collaboratively and it doesn't have to be feature-complete before released. If we choose to do it, it may be best to keep it in a separate github repo in order to make it easier to compile separately without having to compile dmd/druntime/etc. Optionally, but highly suggested: initiate work on D by Example: a searchable collection of up-to-date self-documenting D examples, structured by the topic, like a book. Some of the examples from wiki could be moved there, some Rosetta examples by bearophile and many more. Could be even parts of some libraries or Phobos. The point is, we have more than we need, it's just scattered across the Internet, so we need to unscatter it. I have a basic suggestion on how to get started. Create a Learning D button and put it on the menu at left on the front page. On the page it links to, start by researching and listing every existing resource for learning D, in a kitchen sink kind of way. Now future contributors can know what already exists, and what doesn't. The importance of this list is that anyone wanting to help create new teaching aids can quickly get up to speed on the current state of affairs. They can feel assured that they're not duplicating anyone else's work. As the official list and accessible from the front page, it's more likely to be kept up to date. The point is that it serves double duty both as a treasure trove of learning links, and as a complete reference for future contributors. Destroy, please!
Re: [WORK] groupBy is in! Next: aggregate
On 1/23/15 1:34 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jan 23, 2015 at 12:40:01PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 1/23/15 12:38 PM, bearophile wrote:
Ary Borenszweig:
In most languages group by yields a tuple of {group key, group
values}.
I'm saying this since some years... (and those languages probably
don't use sorting to perform the aggregation).
At some point in the coming years the pain is bound to become
unbearable so you'll give the gift of a pull request. -- Andrei
(!!!)
I knew that pun won't go unremarked! :o) -- Andrei
Re: What to do with InvalidMemoryOperationError
On Friday, 23 January 2015 at 10:13:43 UTC, Joakim wrote: InvalidMemoryOperationError generally means that you are performing certain disallowed memory operations during a full garbage collection, such as allocating while the gc is running. If my app is single-threaded this cannot happen then. This usually happens when you call a function that allocates in a destructor, which will trigger this error as the destructor is run by the gc. It appears that the gc issues mentioned above can also trigger it. If you're running off git head, maybe you can apply that PR 2794 and see if it helps. Otherwise, maybe you've hit some other gc issue somewhere. So if GC.disable prevents the error from occurring I will have a clue, right?
[Issue 14035] New: string concatenation accepts ints in templates
https://issues.dlang.org/show_bug.cgi?id=14035
Issue ID: 14035
Summary: string concatenation accepts ints in templates
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ket...@ketmar.no-ip.org
the following code happily compiles:
template alice (usize ln=__LINE__) {
enum alice = { int t_~ln~ = 42; };
}
pragma(msg, alice!());
it uses `ln` value as character code, which seems to be wrong, as trying to do
the same in ordinary function fails with the following message:
Error: incompatible types for (({ int t_) ~ (ln)): 'string' and 'uint'
--
Re: [WORK] groupBy is in! Next: aggregate
H. S. Teoh: What you describe could be an interesting candidate to add, though. It could iterate over distinct values of the predicate, and traverse the forward range (input ranges obviously can't work unless you allocate, which makes it no longer lazy) each time. This, however, has O(n*k) complexity where k is the number of distinct predicate values. Let's allocate, creating an associative array inside the grouping function :-) Bye, bearophile
Re: forcing @nogc on class destructors
On Friday, 23 January 2015 at 21:00:08 UTC, Steven Schveighoffer wrote: On 1/23/15 3:40 PM, deadalnix wrote: 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. This is as per spec :) No, spec says your dtor is not guaranteed to run for unreferenced memory. It doesn't say your destructor may not be run even when the memory is collected. In fact, it says The garbage collector calls the destructor function when the object is deleted. But my real point is that depending on dtors being called by the GC is not broken 90% of the time. -Steve If the program ends before the next GC the destructor is never called.
Re: What D related (or interesting development based) twitter accounts do you guys follow?
On Sunday, 28 July 2013 at 16:57:54 UTC, Gary Willoughby wrote: What D related (or interesting development based) twitter accounts do you guys follow? I'm pretty new to twitter and trying to follow accounts that i find interesting. Just remembered when reading this: http://www.viva64.com/en/b/0302/ Twitter for C++ Programmers (updated) it appeared here: https://isocpp.org/blog/2015/01/twitter-for-c-programmers-andrey-karpov Yes, it's about C++, but it mentions: WalterBright - @WalterBright - Digital Mars C, C++, D programming language compilers, and Javascript compiler. Andrei Alexandrescu - @incomputable - Please refer to my website for bio and contact information.
Re: Calypso and the future of D
On Friday, 23 January 2015 at 11:26:07 UTC, Walter Bright wrote: On 1/23/2015 3:22 AM, Abdulhaq wrote: On Friday, 23 January 2015 at 10:53:47 UTC, Walter Bright wrote: Yes, it's tied to clang++. It may not even work on all the platforms we support. But that's no matter for now. When you say for now, does that imply that at some time in the future it may matter, in which case isn't it better to get these issues thrashed out now? Is this a potential dead end? We don't need a perfect solution immediately. We do need a solution that's better than nothing, we can build on that as required. I actually agree (though I am nowhere near as well informed as most others on this forum) that Calypso is the way to go, however ISTM there are large implications that go with that decision. The infrastructure that Calyspo depends on is not something, IMO, that you can build on as required to address missing platforms, for instance. Gazing into my crystal ball I'd say that 5 years down the road there will be many D libraries with significant dependencies on C++ (Calypso bound) to the extent that the great unwashed will view D as a language that is only practicable on platforms supported by clang++. For me that is fine, but I suspect not fine for others. For instance, I would view Qt and VTK as key bindings. Others will want numeric libraries etc. etc.. I should also point out that D doesn't have 'nothing' in terms of alternatives, there exist other more traditional binding-based technologies that could flourish with 'official' support. Since I have a hand in one of those I should point out that I think Calypso, if it does what I think it does, will work better in terms of integration, speed etc. and from my personal perspective is therefore better. My goal is to have Qt, VTK, linear algebra, matrices etc., available for D (linux and Windows) and I'm not fussed exactly how it is done.
Re: D on Slashdot
On Thursday, 22 January 2015 at 16:13:31 UTC, ketmar wrote: somehow i can't close cmd.exe by hitting ctrl+c. don't console programs know what ctrl+c is for? Well, maybe because it's a shell, not a utility? shell is a console utility. Hmm... shell is a user interface providing access to the system and utilities. It's different from user utilities in that it's a system component, making the whole thing usable at all. It shouldn't terminate conventionally, because then the user remains without access to the system, that's why console shell doesn't terminate on ctrl-c and GUI shell doesn't terminate on alt-f4. But a text editor should definitely terminate in a conventional manner. strangely, ctrl+c is not working in FAR too. it's not a shell. it's obvious console. Maybe they just don't give a shit about it? Or they see it as a shell. Truth be told, FAR has a quit button at the bottom. It fills in file names which match what you typed, this is exactly what autocompletion is for. What's so difficult to understand there? it's difficult to understand how it does thelepaty. from my expiriense, it's thelepaty is completely wrong each time. and with putting the whole filename i don't even know where was ambiguty (and if it was at all). so afjgjoe means, that this is the only match, or there are more matches? nobody knows, until he hits tab again. and then he lost his afjgjoe and have to either tabbing furiously to get it back, or type it manually. perfectly unusable autocompletion. Well, that's your implementation. In fact shift-tab returns the previous entry. It's a popular reversal modifier, e.g. in a tabbed browser ctrl-t opens a new tab and ctrl-shift-t opens previously closed tab, in a text editor ctrl-z is undo and ctrl-shift-z is redo. Literal means just a value typed in directly instead of being taken from a variable, that's all to it. good luck redefining what the shell does from the times when windows was a term from housebuilding. The term has nothing to do with windows, it's from theory of programming languages, such things usually tend to be quite old, maybe even older than unix. I think, my understanding corresponds to the established one, and bash docs use it too. Some reading: http://en.wikipedia.org/wiki/Literal_%28computer_programming%29 - about literals in general. http://en.wikipedia.org/wiki/String_literal - more about string literals specifically; the Delimiter collision section explains, why string literals need escaping. http://www.gavilan.edu/csis/languages/literals.html - an extensive article about literals; interestingly, Hollerith strings don't suffer from delimiter collision and consequently don't need escaping. i was trying to explain you what's going on. ah, ok, good luck arguing with machine code, telling it that it must do not what it do. Well, it's not really needed. User only types the first characters without quotes, no need for them really; then quotes are added by the autocompletion algorithm, if needed. As I explained, the file can start with a difficult to type character, requiring to type it is unnecessarily daunting. and you know what? if you hit tab twice on empty line in bash, you'll eventually see something like this: Display all 4788 possibilities? (y or n) good luck browsing thru that. On windows you can choose to iterate through some first of them or try something else. There are extreme cases, but they are, well, extreme. User folders are likely to have small number of files.
Re: for ranges
On 1/23/15 4:44 AM, ixid wrote: On Thursday, 22 January 2015 at 16:41:49 UTC, Russel Winder wrote: Playing with factorial implementations, as you do. I had a D implementation using ulong. Not sensible obviously since overflow is a bit of a problem. But the code worked, as did the tests. Now converting to BigInt and… The standard explicit iteration form uses a loop: for(i; 2..n+1) for n = 0 or 1 this loop doesn't loop since the range is [,). However for BigInt: for(i; two..n + one) the loop starts at 0 and just keeps on going. This is clearly not good. Am I having a mental breakdown or is this a real bug? In general it feels as if BigInt needs more work as it doesn't work with simple generic code in too many cases. Templates get confused by invocation with a literal and a BigInt for example when it should have a single type. Literals feel too strongly typed or too weakly implicitly convertible. This is not a BigInt problem, it's an inconsistency with foreach range. See my earlier post. -Steve
Re: why spawn crash?
On 1/22/15 10:20 PM, mzf wrote:
i wrote a test code:
void worker(int firstNumber)
{
Thread.sleep(1.msecs);
}
void main()
{
foreach (i; 1 .. 1000) {
spawn(worker, i );
writeln(i);
}
thread_joinAll();
writeln(ok);
}
sometimes it's ok,sometimes it's crashed ! why ?
here is one of times callstack message:
test.exe!_free ()
test.exe!_fwide ()
test.exe!_fwide ()
test.exe!__ReleaseSemaphore ()
test.exe!_fwide ()
test.exe!main@__modctor() 行 3
test.exe!rt@minfo@__T14runModuleFuncsS482rt5minfo11ModuleGroup11runTlsCtorsMFZ9__lambda1Z@runModuleFuncs ()
test.exe!___threadstartex@4 ()
That sounds like a bug in stdio. fwide is the horrible attempt of C
stdio to do wide character output.
-Steve
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.
Re: Calypso and the future of D
On 2015-01-23 11:52, Walter Bright wrote: Yes, it's tied to clang++. It may not even work on all the platforms we support. But that's no matter for now. At least Clang supports all platforms we support. -- /Jacob Carlborg
Re: dlang.org redesign -- general thoughts and issues [part 1]
On Friday, 23 January 2015 at 10:31:45 UTC, aldanor wrote: 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). i think it'd be great if you and sebastiaan koppe worked together. you guys can get together and combine your efforts so one of the work would not go in vain.
[Issue 14028] [CTFE] Possible reinterpret cast to a pointer to static array
https://issues.dlang.org/show_bug.cgi?id=14028 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/473cef885b499c5620f6dfd93a0a56771d0dd3bc fix Issue 14028 - [CTFE] Possible reinterpret cast to a pointer to static array Use AddrExp + SliceExp (aggr[a..b]) to represent a CTFE pointer to static array. https://github.com/D-Programming-Language/dmd/commit/4a8df52639d963f6278207e7aed694fc10861dc6 Merge pull request #4326 from 9rnsr/fix14028 Issue 14028 - [CTFE] Possible reinterpret cast to a pointer to static array --
[Issue 14028] [CTFE] Possible reinterpret cast to a pointer to static array
https://issues.dlang.org/show_bug.cgi?id=14028 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
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 -- general thoughts and issues [part 1]
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.
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!
[Issue 12406] Broken delegate closure
https://issues.dlang.org/show_bug.cgi?id=12406 --- Comment #1 from Infiltrator lt.infiltra...@gmail.com --- Bug still exists in 2.065. --
[Issue 12209] Unable to take address of function nested function
https://issues.dlang.org/show_bug.cgi?id=12209 --- Comment #1 from Infiltrator lt.infiltra...@gmail.com --- Bug still exists with 2.065. --
Re: I'll be presenting at NWCPP on Jan 21 at Microsoft
On Friday, 23 January 2015 at 05:54:41 UTC, Walter Bright wrote: On 1/22/2015 12:52 PM, Gary Willoughby wrote: Me too, is there any video available? https://www.youtube.com/watch?v=IkwaV6k6BmM I can't bear to watch it, you'll have to do it for me! Mandatory reddit link: http://www.reddit.com/r/programming/comments/2tdy5z/interfacing_d_to_legacy_c_code_by_walter_bright/
Re: forcing @nogc on class destructors
On Friday, 23 January 2015 at 06:16:21 UTC, Jakob Ovrum wrote: Classes don't have to be designed to be allocated on the GC heap. Class instances can be allocated on the stack, the C heap, or anywhere else. …and this is a badly typed design if you don't embed ownership in reference types. But, GC should not call destructors, because classes using RAII will then fail. D is a systems-programming language and should cater to a wide variety of use patterns, including users who wish to use classes in non-GC memory locations. There are way too many weaknesses in current D semantics to make it suitable for systems programming. By systems programming I mean programming that push the hardware to the limits and take advantage of hardware specific properties. The fact that you cannot gracefully recover from low-memory conditions is a bad sign. A good reason for not acquiring resources in destructors is that you can then throw exceptions and recover when you run out of resources. Which is important on high load and/or low memory devices. Perhaps splitting class destructors into two separate concepts, a destructor and a finalizer, with the latter being @nogc, could be a more satisfactory solution. How about banning GC-allocation of classes with destructors?
Re: dlang.org redesign -- general thoughts and issues [part 1]
Hi all, I've started redesigning dlang.org AGAIN (yea, I know...). Appreciate the work you and others are doing on this. Web pages are so fiddly but so important for controlling the image one presents to the world. I don't have so much to say about the general case, as it is not my field. But a couple of thoughts in relation to the content generally. About/History. A link on the front page to a few paragraphs setting the context for how D came about might be good. It's a very powerful story of how Walter came to write D, and Andrei's subsequent involvement. You could replace the Acknowledgements section by this, and place this underneath the story with also a bit more colour on who the other major contributors are - some short bios. Why D?. It's the first question people will want answered when coming to the site, and they have to dig around quite a lot to get the complete picture. FAQ - since the FUD crowd keep bringing it up (see Slashdot discussion of D lang), perhaps the tango vs phobos and D1 vs D2 questions should be answered within the FAQ. Also the DMD is not open source canard. Top-level link: SITEMAP ... should be removed, it's not 1999 anymore. Plus, a well-structured website never needs a sitemap. Honestly, I am not so sure that is right. In the age of the iPad and Kindle, books still have indexes, and they are very useful on occasion, and I think this does apply to websites too, whatever the fashion to day may be. If you know what you are looking for then good structure helps, but one doesn't always know what one is looking for. Top-level-link: VISUAL D ... should move under Downloads Tools; having this at top-level has a Windows smell and may scare people away. Perhaps that is right. However if so, under Downloads and Tools there needs to be a little bit of introduction and context rather than bam DMD2.066.1. If I have just arrived knowing nothing about D and want to get started, what is DMD??? And GDC, LDC. Which one do I pick? Dashing something off quickly: There are three mature compilers for the D programming language. 1. DMD is the reference implementation originated and maintained by Walter Bright, and available for Linux, Free BSD, and OS X. Android/x86 support is mature but not yet fully complete, whilst Android/ARM is currently at a pre-alpha stage.[Link http://wiki.dlang.org/Build_DMD_for_Android] DMD is known for its exceptionally fast compilation times - for example, the standard library, Phobos, takes only XX minutes to compile on a standard Amazon m1.medium image. This brings the benefits of scripting languages such as Python for enabling rapid iterative development; it allows D to be used as a scripting language [link to RDMD] and permits the creation of dynamically compiled extensions to running programs - see DREPL [link] for an example. The compiler is free to use, the full source code is supplied with the compiler, and the front end is fully open source under the Boost(?) license. Although the back end is licensed from Symantec and this is not compatible with GPL-style licenses, all development takes place publicly on github. [Say briefly what can and can't be done under the license and link to the FAQ for fuller explanation of the licensing]. 2. GDC is a fully open-source compiler that uses the Gnu GCC back-end to generate native code and for some applications may generate faster, more optimized code than DMD. It is available for Intel architecture Linux, ARM architecture Linux, and Windows. Android support is under development and not yet fully mature [http://wiki.dlang.org/GDC/Installation/Android] 3. LDC is a fully open-source compiler that uses the LLVM back-end to generate native code and for some applications may generate faster, more optimized code than DMD. It is available for ... The DMD section should have a link to installation instructions as well as how to resolve commonly experienced problems. The download page should also have a section for IDEs and debuggers. Not just Visual D. I suggest it should also have a link to dstep github page and direct link to download binaries for each platform (they are tucked away in a subdirectory). Library interoperability is a key barrier to adoption of D, and when you arrive at the website, it is not obvious immediately how to do this. Maybe on front page there should be a top-level section Interoperability or some more mellifluous title linking to a piece saying the following D fully supports the C application binary interface (ABI), which means that D programs can link to C object files and libraries and achieve full interoperability. The only step required is to translate C .h header files to D format, and this can be done automatically using the dstep tool (available here[link]) or on Windows using the htod tool (available here[link]). Substantial C++ interoperability exists, but this is
Re: [WORK] groupBy is in! Next: aggregate
On 1/23/15 1:36 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Jan 23, 2015 at 08:44:05PM +, via Digitalmars-d wrote: [...] You are talking about two different functions here. group by and partition by. The function that has been implemented is often called partition by. [...] It's not too late to rename it, since we haven't released it yet. We still have a little window of time to make this change if necessary. Andrei? Returning each group as a tuple sounds like a distinct, albeit related, function. It can probably be added separately. We already have partition() functions that actually partition a range into two subranges, so adding partitionBy with a different meaning may be confusing. -- Andrei
Re: forcing @nogc on class destructors
On Friday, 23 January 2015 at 21:00:08 UTC, Steven Schveighoffer wrote: On 1/23/15 3:40 PM, deadalnix wrote: 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. This is as per spec :) No, spec says your dtor is not guaranteed to run for unreferenced memory. It doesn't say your destructor may not be run even when the memory is collected. In fact, it says The garbage collector calls the destructor function when the object is deleted. But my real point is that depending on dtors being called by the GC is not broken 90% of the time. -Steve You are right, on a literal point, but I think that what he was saying was something like: Any application that depends on object being collected in a collect circle as unreferenced, so that depends on destructors are being called by the GC is broken in 9 out of 10 cases anyway I agree with aldanor about his argumentation that a warning would be appropriate: it's a very common pitfall, and a pitfall that simply cast a bad light on the language in newcomers' minds when it occurs at runtime. Also if a lint tool can catch it, we all are conscious of the big effort that the community leaders are putting on picturing a better language for newbies (please, no pun intended, really!) -- Paolo
Re: Calypso: Direct and full interfacing to C++
Nevermind it's just that CodeGen is ambiguous with clang::CodeGen although my compiler doesn't complain. Fixed.
dlang.org redesign n+2 (the one with the bold red vertical menu)
Inspired by the recent developments, and Sebastiaan Koppe's version [1] specifically, I gave it a go, too: http://ag0aep6g-dlang.rhcloud.com/ It's not as radical as other approaches. I didn't start from scratch, but tried to improve on what's there. Almost everything stayed in its place. The only thing that moved significantly is the search box. And I'm not sure about the new spot; may be better to put it above #content again. I worked mostly on the general appearance, not on the content, not on the navigation hierarchy, not on styling specific pages. I did very minor adjustments to the homepage, though. Like fixing the grammar of the slogan ;) And I stole Sebastiaan's tables, as can be seen on property.html, for example. I tried to keep all functionality, not cutting things for the sake of looking clean. I did kill two little details though: * D 2.066.1 in the menu -- What's the point of that linking to the home page? Maybe bring it back as Home. * the GitHub ribbon on download.html -- Because I hate it. The site supposed to scale nicely with window size and font size. E.g., try resizing the window, or pressing Ctrl++ until the layout switches to 'mobile' (go back to default with Ctrl+0). On that note, I changed the main font size to 1em, period. That's a thing I feel kinda strongly about. It's just the right thing to do (TM) in my opinion. I have not been a good committer, so there's lots of cleanup to do. But aside from that, this is supposed to mergeable as it is. Destroy. [1] http://forum.dlang.org/thread/erksyjogigdbhuwpw...@forum.dlang.org
proper groupBy
On Friday, 23 January 2015 at 20:28:32 UTC, Andrei Alexandrescu
wrote:
On 1/23/15 12:19 PM, Ary Borenszweig wrote:
In most languages group by yields a tuple of {group key, group
values}.
Interesting, thanks. Looks like we're at a net loss of
information with our current approach.
@quickfur, do you think you could expose a tuple with key and
values? The former would be the function value, the latter
would be what we offer right now.
That would apply only to the unary version of groupBy.
Andrei
groupby hack below ? I haven't yet read the source code and
don't feel I understand ranges deeply enough to know if this will
work in the general case. But it at least works for the example
(I think).
Laeeth.
#!/usr/bin/rdmd
void main()
{
import std.algorithm, std.stdio, std.range;
auto index=[293, 453, 600, 929, 339, 812, 222, 680, 529, 768];
auto vals=[ 1, 2, 3, 4, 5, 6,
7, 8, 9, 10];
auto zippy=zip(index,vals);
zippy.groupBy!(a= a[0] 1)
.writeln;
}
[root@fedorabox test]# ./groupby
[[Tuple!(int, int)(293, 1), Tuple!(int, int)(453, 2)],
[Tuple!(int, int)(600, 3)], [Tuple!(int, int)(929, 4),
Tuple!(int, int)(339, 5)], [Tuple!(int, int)(812, 6), Tuple!(int,
int)(222, 7), Tuple!(int, int)(680, 8)], [Tuple!(int, int)(529,
9)], [Tuple!(int, int)(768, 10)]]
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On 1/23/15 9:03 AM, aldanor wrote: 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. [snip] These insights are solid, sorry for not explicitly stating my position earlier. My suggestion for these ideas to materialize is to initiate pull requests for everything that is a net improvement on the state of affairs, and create issues for the larger items that need more collaborators or longer spans of work. I will preapprove appropriately. Incremental is key here. Of this list of desirable things, what is one thing that could be done now and result in a better site? For example Panke updated wc.dd. Now we're in a better place than before, even if say in a month's time we decide to replace the example completely. I restate: if you provide me a simple way to fill a step-by-step tutorial, I'll happily do it. Andrei
Re: dlang.org redesign n+2 (the one with the bold red vertical menu)
On Saturday, 24 January 2015 at 02:43:47 UTC, anonymous wrote: Inspired by the recent developments, and Sebastiaan Koppe's version [1] specifically, I gave it a go, too: http://ag0aep6g-dlang.rhcloud.com/ Interesting, and just for fun I changed the CSS a bit: http://i.imgur.com/ijLxXe2.png :) Matheus.
Re: Calypso: Direct and full interfacing to C++
On Friday, 23 January 2015 at 23:06:16 UTC, Kelly wrote: People might still need the small quick fixes for gen/cpp/assistbuilder.cpp, but just adding clang:: in a couple spots shouldn't be too arduous for anybody if they really want to compile and play with Calypso. Weird, assistbuilder.cpp compiled fine here with up-to-date Clang 3.5. Did you checkout the 3.5 branch?
[Issue 14033] runtime error about auto ptr = cast(T*)buf , T is class type
https://issues.dlang.org/show_bug.cgi?id=14033
--- Comment #3 from mzfh...@foxmail.com ---
i see,class and struct,their memory model is different,thanks.
struct stTest
{
int a;
int b;
void foo(){}
}
class clsTest
{
int a;
int b;
void foo(){}
}
void main()
{
int [100] buf ;
auto stPtr = cast(stTest*)buf;
stPtr.a = 123;//ok
stPtr.foo();//ok
auto clsPtr = cast(clsTest)buf;
clsPtr.a = 123;//ok
clsPtr.foo();//run time error,vfptr is not be assigned.
}
--
