Re: Digital Audio Workstation in D
On Sunday, 14 February 2016 at 21:57:38 UTC, Tanel Tagaväli wrote: This may be a pipe dream, but I want to create (with the help of other developers, of course) a DAW using D. The reasons are mainly: + The design can be very complex + Realtime playback is a requirement + You can do a lot of things with audio It would be interesting to see how D could handle a big project such as this. I can't do it on my own, however. So I'm asking, is there anyone in the D community who would be interested in a project of this likeness? A DAW is a major undertaking that would test the language boundaries for sure. The real time requirements mean that the GC is excluded. Cockos, the makers of REAPER, have a few C libraries that could be used, among which a solid VST wrapper and general libraries that they use in their software. As for audio, it's also worth having a look at the JUCE C++ lib.
Great new website
Hey, just a post to say how cool the new website is. I can browse it on an iPhone without issue.
Re: Stroustrup's slides about c++11 and c++14
On Monday, 15 September 2014 at 18:17:37 UTC, bearophile wrote: Andrei Alexandrescu: C++ intelligentsia seems to have a superiority complex with regard to D, and that's entirely understandable. D and C++ compete for a similar programming niche, but C++ is so much widespread compared to D, that it's like comparing a blue whale with an ant. In practice there is no real match and competition. D is not going to replace C++ in the next few years, and probably it will not eat a significant percentage of the C++ pie. So I think it's a good idea to have a little more collaboration between the two language communities. Such superiority complex is not going to help any one. Bye, bearophile The problem is, the C++ community is unwilling to collaborate with anyone else and this attitude is encouraged by Stroustrup.
Re: Tail pad optimization, cache friendlyness and C++ interrop
On Saturday, 21 June 2014 at 10:49:57 UTC, Artur Skawina via Digitalmars-d wrote: It's not about being able to contribute to DMD, it is about being able to work on /other/ projects. If contributing to DMD carries the risk of affecting the latter then it's simply best to avoid it; it's not a risk worth taking, just for a few small improvements. Significant work often starts with simple and trivial fixes; if scratching-an-itch is too costly then major contributions suffer too. Note that whether the risk is significant, or even real, doesn't really matter much -- it's the cost of making the decision that matters. Just-submit-a-small-patch-to-a-boost- -licensed-project turns into investigate-the-licensing-and-evaluate-all- -the-potential-legal-implications. It's enough to discourage submissions *even in the cases where there is no problem*. artur I really don't see what the issue is. If the projects are unrelated, there is no reason there could be a contamination. And even with that, nothing prevents you from working on the front end with LDC or GDC.
Re: shorter alternative of constructor with parameter
On Saturday, 21 June 2014 at 21:25:33 UTC, Kapps wrote: Personally I'd definitely welcome this syntax. It's an extremely common thing to do, prone to typos / bugs, is a simple syntax, and is something I'm surprised more languages don't have. I've never seen a single instance of a bug like this in 15 years of Java and C++ programming. One has to be really sloppy in order to insert bugs in such simple code.
Re: [OT] Extra time spent
On Sunday, 8 June 2014 at 13:50:47 UTC, Andrei Alexandrescu wrote: Yah. One well-known fact about Facebook is it has an open layout which can be quite distracting. One less-known fact is it makes high quality headphones (both in-ear (Klipsch) and over-the-ear (Sennheiser)) available to all employees for free. -- Andrei That is **awesome** !
Re: [OT] Extra time spent
On Monday, 2 June 2014 at 14:19:32 UTC, Steven Schveighoffer wrote: On Sun, 01 Jun 2014 15:22:44 -0400, Walter Bright newshou...@digitalmars.com wrote: On 5/30/2014 8:08 AM, Chris wrote: I like to re-invent the wheel too, because existing wheels might not be fit for your purpose. A few years back I invented a triangular wheel, which was an improvement over the square ones because it had one less bump. How do you fix the square bearing problem? I still can't figure that one out. -Steve https://www.sciencenews.org/article/riding-square-wheels
Re: [OT] Extra time spent
On Tuesday, 3 June 2014 at 18:14:29 UTC, Walter Bright wrote: On 6/2/2014 11:55 PM, Jacob Carlborg wrote: I'm also listening to music on the phone. I've damaged my ears from years of loud engines. I've read that most hearing damage comes from gunshots, rock concerts, and earphones. When using earphones in public, one tends to turn up the volume to drown out the ambient noise. Worrying about that, I just don't use earphones in public. You want in ear isolating earphones. Basically earplugs that play music. Since the ambiant noise is greatly reduced, you don't need to play loud at all. Some brands isolate more or less well. Etymotics isolate very well.
Re: [OT] Extra time spent
On Friday, 6 June 2014 at 18:40:28 UTC, David Gileadi wrote: In my experience a good manager protects you from outrageous demands from the customer. Just the kinds of examples that were mentioned earlier in this thread, in fact. I'm lucky to have had a couple of managers that actually do this, and I'm super grateful for them. In my experience, the best software managers were good coders who moved to management positions, or managers who don't hesitate to sit next to coders to really try to understand what the issues are.
Re: [OT] Extra time spent
On Friday, 6 June 2014 at 19:49:48 UTC, deadalnix wrote: Techie A: Man we really fucked by choosing ruby on rails. Our codebase has become unmaintainable. We must do something. Technie B: Let's migrate to Node.js ... and use mongodb as our new shiny database. 'cuz it's so kewl and webscale. 6 months pass... Technie B (now looking for a new job): let's write a blog post on how mongodb fucked our project
Re: [OT] Extra time spent
On Friday, 6 June 2014 at 18:51:17 UTC, Mattcoder wrote: Well, some managers are mindless and that story about do it now or we will lose our customer, in most cases it's just a bluff/threat or call it what you want. Unfortunately, commercial's bonus is based on their selling performance, so they will sell anything they can, even if it doesn't exist yet. Especially if they need to win a contract in face of competitors. OTOH, if the contract is won, the company has an obligation to deliver. I've saw some programmers complaining about their managers, but what I really would like to see are these programmers joining together to convince the manager the problems with fast and low quality software, and how their company will lose money fixing it later. Matheus. It's hard, because most managaers more or less know that, and they prefer to get the money right away and deal with tech issues later, hoping that they are overblown by the dev team and won't jeopardize entirely the project. From an economic POV, it's the right thing to do. The benefit of this is getting the contract in face of the competition; but if the quality is too low, the risk is losing the customer at the end and getting a bad reputation. The company I work for has been somewhat guilty of this attitude, selling an unfinished product for quite a large amount of money. The problem is, the customer still hasn't paid us a year later, because of many technical instabilities (not mentionning obvious corruption problems on the customer side). Today, the product has mostly stabilized, but we're still running after our money.
Re: For Chuck Allison: possible homework in D
On Saturday, 7 June 2014 at 06:48:39 UTC, Philippe Sigaud wrote: I was watching Chuck Allison talk yesterday, and wondered what could be a possible homework in D. Maybe other people here have some ideas, maybe Bearophile will point to RosettaCode, I don't know. Thoughts? Do other people here have homework ideas? Also write D programs for the Computer Language Shootout, in an idiomatic way or as fast as possible (without resorting to pure C or assembly).
Re: Thanks for a great DConf
On Sunday, 25 May 2014 at 18:37:46 UTC, SomeDude wrote: On Saturday, 24 May 2014 at 23:37:44 UTC, aliyome wrote: On Saturday, 24 May 2014 at 20:34:03 UTC, monarch_dodra wrote: On Saturday, 24 May 2014 at 17:40:29 UTC, Nick Sabalausky wrote: I'm looking forward to the YouTube reruns for the talks I still missed. (I still can't believe I missed Andrei's keynote!) +1 please. me too. +1 The videos are online on Dconf. Now, maybe Andrei wants to distill them on reddit and HN in order to give more coverage, so I didn't create a new thread there. Oops no, how stupid I am, I clicked on the 2013 link. Sorry...
Re: Thanks for a great DConf
On Saturday, 24 May 2014 at 23:37:44 UTC, aliyome wrote: On Saturday, 24 May 2014 at 20:34:03 UTC, monarch_dodra wrote: On Saturday, 24 May 2014 at 17:40:29 UTC, Nick Sabalausky wrote: I'm looking forward to the YouTube reruns for the talks I still missed. (I still can't believe I missed Andrei's keynote!) +1 please. me too. +1 The videos are online on Dconf. Now, maybe Andrei wants to distill them on reddit and HN in order to give more coverage, so I didn't create a new thread there.
Re: Safe Navigation Operator “?.” for D2 ?
On Friday, 28 February 2014 at 11:21:47 UTC, Marc Schütz wrote: On Friday, 28 February 2014 at 11:11:28 UTC, Dicebot wrote: On Friday, 28 February 2014 at 09:24:23 UTC, John Colvin wrote: Chaining . operation is a code smell to begin with It is? Why? If a system is well-designed, then null state either means something (and needs to be explicitly handled) or is not possible. ?. provides simple and easy way to write a sloppy code that does not tell the reader if resulting code flow for null case was intentional. Also it is very easy to get accustomed to use ?. everywhere instead of . and get broken logic instead of NullPointerException for cases when pointer is wrongly assumed to never be null. I sometimes come across situations like this: writeln_or_whatever(person ? person.name : ); (This is a case of means something.) Using `person?.name` is a bit shorter and DRYer. But it would be more useful if I could specify the default value it returns. With an explicit `maybe` this would be possible: person.maybe(n/a).name; I am also on the opinion that chaining on nullable objects encourages sloppy code and should therefore be avoided. Because the null case should often be handled. Chaining skips handling the null case. Thus this syntaxic sugar is a bad idea. The chaining pattern is okay to make code more expressive, but it is always assumed that the objects on which it's applied are non-nullable.
Re: Top-3 for 2.066
On Wednesday, 26 February 2014 at 01:34:36 UTC, Mike wrote: On Wednesday, 26 February 2014 at 01:32:43 UTC, Mike wrote: I created an enhancement request here: https://d.puremagic.com/issues/post_bug.cgi. Damn! Here's the correct link: https://d.puremagic.com/issues/show_bug.cgi?id=12259 Mike You didn't explain why you need this feature and its benefits. Allowing multiple votes per user obviously skews the results and defeats the purpose of voting.
Re: Top-3 for 2.066
On Tuesday, 25 February 2014 at 12:35:18 UTC, Namespace wrote: 3. ref doesn't accept rvalues. Can't declare ref locals (pointers change semantics). These above anything else are interfering with my work every day. What are yours? Every year again: rvalue references. :) I'm not in a hurry seeing this added to D. In fact, I think we should wait a few years for C++ feedback on this feature. It might be that in a couple of years, the gen eral consensus is that it was not such a great idea after all, or that the implementation could have been improved in such or such way. The current body of experience is not large enough for a clear view.
Re: Top-3 for 2.066
On Saturday, 1 March 2014 at 05:00:08 UTC, Mike wrote: On Saturday, 1 March 2014 at 03:47:37 UTC, SomeDude wrote: You didn't explain why you need this feature and its benefits. I didn't think an explanation was necessary, but ok. Right now there's no way to quantify your preference. You can only say you want the bug fixed or you don't. You don't get to say how badly you want it fixed. Being able allocate more of your allowance to something allows you to quantify its value. To allocate more towards one issue gives you less to allocate towards other issues. I didn't get it was in the context of keeping a limited number of possible votes. I understood the original request was to remove the cap on votes/person. Those two features are mutually exclusive. What coud be also possible is capping a number of votes/person/month (if the system allws that). That would allow someone to cast 12 votes/year on a single bug. Still, I don't like the idea of someone casting several votes on a bug, unless we also display the number of different voters next to the total number of votes. Because a bug with 10 votes from 10 different voters is arguably more important than a bug with 10 votes by a single voter.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Monday, 17 February 2014 at 06:32:19 UTC, Paulo Pinto wrote: Well, supporting modules would already help. With luck C++ will get them around 2020. I think it won't matter by then. -- Paulo Someone said that 10 years ago. Whether it's true 5 years from now entirely depends on the state of the alternatives by then, not on the state of C++. Don't underestimate the resistance to change.
Re: D as A Better C?
On Tuesday, 11 February 2014 at 21:55:49 UTC, Francesco Cattoglio wrote: If you hate too many Ds, then the best name is by far D flat: D♭ Or rather D minor. Or what about AC ? Cuz AC is D C. Or Washington (D C). EmbeD wasn't too bad. It allows In bed with EmbeD.
Re: D as A Better C?
On Thursday, 13 February 2014 at 06:51:37 UTC, 1100110 wrote: Please, I beg you! No new names. Please don't fragment the language. Just make it a little more modular. Mike I agree, if this is strictly restricting the language to a core subset, then I cant see it having any effect. If you don't like it don't use it. But you can't use Phobos. Practically, that would mean rewriting a lot of Phobos, or another standard library.
Re: forum.dlang.org moved to a new server
Le 21/12/2013 21:30, Vladimir Panteleev a écrit : Hi everyone, DFeed (the software running on forum.dlang.org) has been moved to a much faster server. My apologies to everyone who had to endure the slow page load times or failures during the old server's nightly maintenance. This move has been overdue for too long. The old server is now acting as a proxy, so there should be no downtime due to cached DNS records. Please let me know here or on IRC if you notice any problems. Well, with the old server I often faced XHR (XMLHTTPRequest, I suppose) errors on Chrome (Win7), especially at night (UTC +1). With the move to the faster one, I've never succeeded in retrieving a single post. So I've gone back to Thunderbird, which works beautifully, BTW. Oh, and it's not so easy to find the name of the news server on the website.
Re: forum.dlang.org moved to a new server
Le 25/12/2013 14:06, Vladimir Panteleev a écrit : On Wednesday, 25 December 2013 at 11:03:14 UTC, Somedude wrote: Well, with the old server I often faced XHR (XMLHTTPRequest, I suppose) errors on Chrome (Win7), especially at night (UTC +1). With the move to the faster one, I've never succeeded in retrieving a single post. Could you please post which web browser and version you're using, and if you could be troubled, a Wireshark capture of a failed attempt to retrieve a page? Chrome Version 26.0.1410.64 m Updated to Version 31.0.1650.63 m (latest), but it didn't change anything. You can get the Wireshark generated pcap file here: http://www.filedropper.com/xhrerrorpcapng Oh, and it's not so easy to find the name of the news server on the website. On the forum index, there is an Also via column. That contains NNTP links. Ah, right, I overlooked that, thx. XHRError.pcapng.gz Description: GNU Zip compressed data
Re: forum.dlang.org moved to a new server
Le 25/12/2013 14:10, Sergei Nosov a écrit : I've also experienced such behavior. Some image with worms (502 error, I guess) on every thread. The issue was resolved when I cleaned up all the dfeed cookies. Ah, thanks for the tip, cleaning the forum cookies has resolved the issue for me too !
Re: Go compiler moving from C to Go
On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile wrote: Russel Winder: The whole point of Go is to replace C, I didn't know this. Bye, bearophile Because it's no longer true at all. It was the goal at the beginning, but it's no longer, they've said that Go is not a system programming language (in the sense that you can construct an OS with it).
Re: This forum is often slow, not responding
On Tuesday, 17 December 2013 at 21:56:01 UTC, inout wrote: I don't think it's the forums' issue - news.digitalmars.com was failing (although the forums could do a better job of recovering from timeouts). I think it has to do with the hosting provider. Every night (UTC+1), the forum is down. Looks like there is some maintenance that stops everything.
Re: D vs Go in real life
On Friday, 22 November 2013 at 15:52:31 UTC, Andrei Alexandrescu wrote: Ary Borenszweig a...@esperanto.org.ar wrote: On 11/21/13 6:36 PM, Andrei Alexandrescu wrote: On 11/21/13 1:16 PM, Gary Willoughby wrote: On Thursday, 21 November 2013 at 16:23:07 UTC, Andrei Alexandrescu wrote: Fortunately a lot has changed since :o). Please, do tell. ;) Not much that people don't know already. We have one solid D project installed and a couple of heavy-hitting engineers have started using D for scripts and tools (e.g. replacing Python for a 2x speedup for the same source code size/complexity). I would have expected a lot more speedup than just 2x, D being a compiled language. Amdahl's law. Andrei BTW, D needs a multithreading example here: http://saml.rilspace.org/moar-languagez-gc-content-in-python-d-fpc-c-and-c
Re: D vs Go in real life
On Thursday, 21 November 2013 at 09:33:04 UTC, Bienlein wrote: What puzzles me is the enormous activity in the Go forum. Only the Python forum has that much traffic. It seems to me that people are all that happy if they have a language with which they can just start hacking around on something. That is because Go doesn't force anyone to think about design. The only design-level construct it has is the class an that's it. Embedding is truly only to save coding effort not having to type in dereferenciation chains as in C. There is nothing except classes, but no inheritance, traits, mixins, overriding, etc. So there is nothing that forces you to think about your design in Go. And you don't have to know about manual memory management as in Rust. -- Bienlein That actually makes it a good first language to learn programming (and also bad programming). Simplicity is appealing. A language that can be learnt in a couple of afternoons is always pleasant and will draw masses. OTOH, if it doesn't force you to think about design, I guess the absence of design bites you in the long term. Then, the simplicity of the language added to the fact that it's statically typed might allow for fairly sophisticated refactoring using tooling. These are just suppositions, I don't have any experience with Go.
Re: DIP 50 - AST macros
On Sunday, 17 November 2013 at 10:41:46 UTC, Jacob Carlborg wrote: We already have templates and operator overloading. Perhaps we should remove those, we don't want to take the chance of people abusing them. D templates have been designed with the past experience of C++ templates in mind, so the mistakes have been avoided. With macros, we don't have much experience; Lisp macros can't count as the language is too different. Basically, people want to change the language, but without having to discuss their own extensions in the newsgroups. It's sometimes handy, but you'll end up with crappy features all over the place. No, people want a general solution that doesn't require the language to be extended each time they come up with a useful feature. Sorry but I tend to value the feedback of people who have already put some serious effort in expression templates and mixins like Don.
Re: DIP 50 - AST macros
On Monday, 18 November 2013 at 22:09:35 UTC, Dicebot wrote: On Monday, 18 November 2013 at 21:09:26 UTC, Jacob Carlborg wrote: On 2013-11-18 16:59, Dicebot wrote: Anything that allows it routinely should be banned whenever macros are accepted or not. Modifying existing normal symbols = no way. The whole point of macros is to modify symbols. Turning this: auto p = Person.where(q = q.name == John); To an SQL query. You don't need to modify actual input lambda for this to become SQL query. I fully support macros as convenient way for AST reflection and related code generation but not a single step further. Changing semantics of existing valid piece of code is never worth it. And that's exactly the kind of thing Walter doesn't want to see.
Re: DIP 50 - AST macros
On Thursday, 14 November 2013 at 22:06:06 UTC, deadalnix wrote: mymacro(4+3); // = can be hello myfunction(4+3); // = can be hello as well Quite frankly, this isn't really convincing. True but you will hardly use myfunction as an extension to the language. If I understand the issues, I quite understand Walter's reluctance to add such a feature. Once you add it, you add the capability to change the language, or to create an entirely new language. If you let it, no matter how loud you cry, people *will* abuse the feature, and they will do it from day one. The C++ templates experiment shows what happens when you do that. We don't want to repeat the same mistakes. Basically, people want to change the language, but without having to discuss their own extensions in the newsgroups. It's sometimes handy, but you'll end up with crappy features all over the place.
Re: DIP 50 - AST macros
On Thursday, 14 November 2013 at 19:42:36 UTC, Zsombor Barna wrote: D's syntax remains the same ( statements, expressions, function calling, numbers etc. ). These AST manipulation tools just define new words or language constructs. Human languages tend to be altered as times passes and the needs change. That's why new words appear. Even the grammar is not the same as the one my grandparents used. Which shows all the problems raised by Walter: 1. you need an entry in the dictionary that you need to look up for each new word that someone has introduced, 2. with natural language, you don't need to know its *exact* semantics when you use a new word, while in programming it is mandatory, 3. you *don't* want your programming language to arbitrarily change over time. That's probably the biggest issue.
Re: Look and think good things about D
On Friday, 15 November 2013 at 01:09:53 UTC, bearophile wrote: I have created two interesting D entries for this Rosettacode Task, is someone willing to create a Reddit entry for this? They show very different kinds of code in D. http://rosettacode.org/wiki/Look-and-say_sequence#D Bye, bearophile I have a task if you are interested, but I didn't bother to login to create it. So if you like, you can create the page... Here it is: In a sequence of a million random integers, return the length and the indexes of the longest duplicate sequence (display indexes counting from one, not zero). In order for everybody to start with the same random sequence, it may be useful to specify a simple implementation for the generating function.
Re: Look and think good things about D
On Friday, 15 November 2013 at 13:33:33 UTC, bearophile wrote: If you use ranges badly you will get a slow program, if you use them well with a good back-end, you will have a fast program. And so, what are the rules for not using ranges badly ? What should be avoided ?
Re: What is the closest to ConcurrentHashMap and NavigableMap in Java?
On Friday, 15 November 2013 at 22:22:32 UTC, Jacek Furmankiewicz wrote: Sohow does Facebook handle it with their new D code? No GC at all, explicit memory management? AFAWK, Facebook doesn't use D for its core business yet, only for buiding tools. OTOH, Andrei has been working hard on memory allocators, so maybe that's one idea that they are digging.
Re: dchip is a D2 port of the Chipmunk2D physics library for 2D games
On Friday, 8 November 2013 at 05:04:45 UTC, Suliman wrote: I did not refactor, it's a straight port. Could you say how much code lines can be approximately saved after porting with refactoring? This question doesn't make much sense. I guess one could write the same thing from scratch in D in half the LOC. But a reduced line count wouldn't be the only benefit, a more maintainable and safer codebase would be other benefits.
Re: D french-speaking community
On Saturday, 9 November 2013 at 04:16:57 UTC, Timothee Cour wrote: french as well (although living in US). +1 !
Re: Why the @ in @safe? UDAs
On Thursday, 7 November 2013 at 20:16:46 UTC, Jonathan M Davis wrote: With regards to the cost/benefit ratio, such a change fails miserably. This is exactly the sort of change that Walter and Andrei were talking about stopping completely at dconf, precisely because it doesn't actually fix anything. Breaking changes need to provide real, tangible benefits which are greater than the cost that they incur. And while I tend to agree that it would be better had none of the built-in attributes used @, changing it won't fix any bugs and won't make any software easier to mantain save perhaps for a tool which lexes/parses the language, and handling the few built-in attributes with @ is trivial in that case. The benefits are aesthetic, and changing it requires changing pretty much all existing D code. And even if you can avoid having the change break code immediately, it still requires changing the code, so it's not like that eliminates the cost of the change. It just spreads it out. If you want anything like this to happen, you'll have to convince Walter and Andrei, and I would be shocked if they were ever convinced. They want to focus on stability, not on tweaking everything in search of making the language perfect. Breaking changes - especially breaking changes on this scale - need to provide real, tangible benefits which outweigh the cost of the breakage. And changing the @ attributes doesn't even come close. - Jonathan M Davis I would add that constant breaking changes make the language unfit for industrial usage in the long term. Let's remember that D is being pushed in production by Andrei at Facebook. If the language breaks everything at each release, there is no way Facebook or any other company for that matter is going to bet a dime on it.
Re: Maintain notes for D's successor? [Was: Re: Why the @ in @safe? UDAs]
On Friday, 8 November 2013 at 14:21:45 UTC, Dicebot wrote: Thread hijacking achievement unlocked ;) On topic of such wiki page - it is kind of nice to have but lot of potential entries are controversial and need some serious discussion (for example, I'd place optional parens there as damaging mistake but reasonable people will disagree :P) before being documented. It risks being biased to preferences of view editors or turn into edit wards :) I don't know what is a good way to do this without devoting too much efforts. You could allow comments at the bottom of the page, or like wikipedia, add a comments page to the DIP ?
Re: Why the @ in @safe? UDAs
On Thursday, 7 November 2013 at 07:50:35 UTC, Daniel Kozak wrote: On Thursday, 7 November 2013 at 07:29:16 UTC, Jacob Carlborg wrote: On 2013-11-07 07:48, Rob T wrote: I agree with you. Unfortunately the those with commit access do not agree. They have no interest, what so ever, in breaking backward compatibility due to consistency. The result is exactly what happened with D1. At some arbitrary point in time it was decided that backwards compatibility must be kept, almost at all cost. This was decided even though the language and the standard library was far from stable. If this is true, than D lost a chance to became more popular, unfortunately :'( In the contrary, ensuring stability gives it a chance to be accepted/supported by major industrial players (like Facebook for instance), which would help boost the language's development and ecosystem.
Re: D french-speaking community
On Saturday, 9 November 2013 at 15:36:08 UTC, Raphaël Jakse wrote: Le 09/11/2013 16:10, Andrei Alexandrescu a écrit : On 11/9/13 1:49 AM, Raphaël Jakse wrote: tranche seems more undertandable to me in this context than morceau, though morceau is an interesting option I didn't consider :-). There's also coupe. coupe is great, I like it. With tranche, I can't help thinking about a cake or a pie, even if also applies to bread. However, coupe implies a loss of dimension: we go from 3D to 2D, or from 2D to 1D. It's more like (cross-)section in English. What do you think ? Andrei I think coupe is really cut (or section as you say), while tranche is really slice.
Re: D french-speaking community
On Saturday, 9 November 2013 at 09:56:54 UTC, monarch_dodra wrote: On the contrary, the French seem to like *everything* to get translated, to the point where the French themselves get confused by the double standard. For example, for stack/heap, the French have tas/pile. I'm French myself, and I can never remember which is which! Why couldn't they just keep stack/heap? Heap = tas Stack = pile Queue = file d'attente
Re: D french-speaking community
On Saturday, 9 November 2013 at 17:03:38 UTC, Graham Fawcett wrote: Tranche seems better to me, because the translation is so direct. The term slice isn't any more semantically accurate in English than tranche would be in French. We aren't actually taking a slice of an array, after all: that would imply that the original array was now missing a piece. :) As a weak francophone, if I saw tranche in a french D article, I would know exactly what it meant, while partie would seem more ambiguous IMHO. Just my two cents (bien que nous n'avons plus des cents au Canada!), Graham Pareil. And using too generic words like partie may actually make it harder to explain things.
Re: D french-speaking community
On Saturday, 9 November 2013 at 10:47:45 UTC, Raphaël Jakse wrote: For templates, the English word is so widespread and Modèle (maybe also template) is such an abstract word that putting the English word in the title seems necessary and useful and that could ease comprehension and searches in the tutorial :-) And modèle isn't even a widely accepted translation. I have seen the word patron in books. That one is even less agreed upon than modèle, and my french C++ programmers commonly use template. Another option is to use the adjective générique. But you then need to join it to a name, like classe, or méthode, or fonction.
Re: Early review of std.logger
On Monday, 21 October 2013 at 08:50:50 UTC, Robert Schadek wrote: disk. That feature proved very useful. That was a feature you added or was it part of the logging library? We added it. I don't know of any logging library doing that.
Re: Early review of std.logger
On Thursday, 17 October 2013 at 07:34:28 UTC, qznc wrote: On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton wrote: The strength of this is that it would allow us to freely integrate D libraries that use std.logger, yet filter their log output from *outside* the library through the std.logger API. This is one of the most important aspects in my opinion. Std.logger should be easy to use, so library writers are encouraged to use it. Compare this with the unittest keyword, which makes it easy to write some simple tests. Of course, flexibility to use complex machinery for using the messages/tests is necessary. Just like we can hook up more advanced unit testing frameworks, we should be able to hook up more advanced logging machinery. The advanced stuff is not for Phobos though. Advanced stuff for unittests is for example, parallel execution and graphical reports. Advanced stuff for logging is for example log rotation and networking. There is no contradiction. Complex log libraries become (relatively) complex when one wants to use their advanced features, but are as simple as the others when one wants to use them simply. That's why in the Java world nearly everyone uses Log4j instead of the official JEE API. In practive, you really want a powerful logging facility. Another feature I used once in a project, was to log to RAM. We decided to log TRACE logs in production in order to catch a rare bug, but of course, it would output too many logs. So we decided to log everything in RAM and keep the last 1000 logs. Whenever there would be an exception or a CRITICAL log, the whole 1000 logs would be dumped on disk. That feature proved very useful.
Re: Early review of std.logger
On Tuesday, 15 October 2013 at 08:47:00 UTC, Robert Schadek wrote: On 10/15/2013 09:32 AM, Sönke Ludwig wrote: Am 15.10.2013 09:08, schrieb Jacob Carlborg: On 2013-10-14 23:22, Dicebot wrote: If we need to care about that, D module system is a failure. But I don't think it is a valid concern. People already complain about conflict function names in Phobos. And I'd agree with them. At least inside of a library, care IMO should be taken to minimize overlap (of course functionally equivalent ones in different overload sets are fine, though). But in case of logXXX this seems to be very unlikely, much in contrast to log (std.math.log). yes and no. Of course does logXXX create less conflict, but I like to simply write log and don't care about the LogLevel. So again pros and cons I for once have never seen any log API with log.level = INFO; Logger.log(Here be dragons); And this I believe for a good reason: in 99% of production code I've seen, several log levels are mixed, i.e INFO, CRITICAL and DEBUG for instance, so the case where a single log level is used, even in the same method, just never happens. The proposed solution looks extremely inconvenient to me as it will almost always necessit two lines of code instead of one. I am with Sönke on this one, as well as the need for multi logger output. That's the absolute minimum requirement. If this doesn't exist, what will happen is, someone will make something better.
Re: Early review of std.logger
On Monday, 14 October 2013 at 13:25:00 UTC, Robert Schadek wrote:
On 10/14/2013 02:51 PM, Andrea Fontana wrote:
Just for comparison, on Android you can write something like:
FileLogger.w(...) instead of
FileLogger.log(LogLevel.Warning...)
(and there's a wtf loglevel for temporary debugging)
hm, I don't really like it. To me it sounds like, I'm don't
care about
log level just print this. Maybe changing the LogLevel type to
an int
like debug(int) { would be an idea and than providing some
immutable
int Info = 1, Debug = 256, Error = 1024 ... would be a idea.
IMHO, Andrea's suggestion is still a million times better.
And in any case, logger.info(...) is much better than
logger.log(Logger.INFO, ...), which is uselessly redundant and
quite ugly.
Re: Pragmatic D Tutorial
On Tuesday, 8 October 2013 at 00:29:34 UTC, Meta wrote: Sometimes D is criticised, because it is not simple language, in contrast to Go, Rust, Lisp, or Scala. However, a D programmer sees no problem and actually likes his big toolbox. I wouldn't call any of those languages simple, except for Go. Maybe Go, C, Scheme, Python? +1
Re: etc vs. package mangers
On Saturday, 12 October 2013 at 23:12:03 UTC, Jonathan M Davis wrote: - Jonathan M Davis OK, for libraries that are not well supported on all platforms, that makes sense.
Re: D minions - time to vote!
On Friday, 11 October 2013 at 07:10:00 UTC, Jonathan M Davis wrote: On Thursday, October 10, 2013 10:28:15 Walter Bright wrote: https://news.ycombinator.com/item?id=6527104 I find how many negative votes D is getting to be a bit depressing, though at least we're doing better than C++ (percentage-wise at least). But as much as I like D, I confess that I find the fact that C++ gets so many negative votes a bit odd. It has its faults, but I'd still say that C++ is better than most of the languages on the list. To each their own, I guess. - Jonathan M Davis You can even find 29 guys who like Cobol. Experimental error I suppose.
Re: std.linalg
On Saturday, 12 October 2013 at 06:24:58 UTC, FreeSlave wrote: For these cases we may let users to choose low-level backend if they need. High-level interface and default implementation are needed anyway. I called it std.linalg because there is website http://www.linalg.org/ about C++ library for exact computational linear algebra. Also SciD has module scid.linalg. We can use std.linearalgebra or something else. Names are not really important now. Ok, things are more clear now. Today I look what I can do. There are litterally dozens of linear algebra packages: Eigen, Armadillo, Blitz++, IT++, etc. I was not complaining about the linalg name, but about the fact that you want to make it a std subpackage. I contend that if you want to make it a std package, it must be nearly perfect, i.e better performing than ALL the other alternatives, even the C++ ones, and that it's really good as an API. Else it will be deprecated because someone will have made a better alternative. Given the number of past tries, I consider this project is very likely doomed to failure. So no std please.
Re: etc vs. package mangers
On Monday, 7 October 2013 at 07:12:13 UTC, Jonathan M Davis wrote: On Monday, October 07, 2013 08:36:16 Jacob Carlborg wrote: On 2013-10-06 22:40, Andrei Alexandrescu wrote: I think /etc/ should be a stepping stone to std, just like in C++ boost is for std (and boost's sandbox is for boost). Currently etc seems like where C bindings are placed. That's what I thought that it was for. I don't remember etc ever really being discussed before, and all it has are C bindings, so the idea that it would hold anything other than C bindings is news to me, though I think that we should probably shy away from putting C bindings in Phobos in general. - Jonathan M Davi The problem is, if these C bindings are removed, the immediate reflex will be to think that Phobos doesn't have the features that were fulfilled by these bindings. So the impulse will be to reinvent the wheel, when these bindings are perfectly okay and do the job well. C bindings is a way to save us time and build upon proven quality libraries. I don't see any problem with C bindings being in the standard library, as long as they are really useful and high quality. The not invented here itch is a bad one. The workforce of the community should be directed at real problems and filling real gaps, rather than being wasted at reinventing the wheel merely for aethetic/ideological reasons. I don't see any need to remove etc.
Re: std.linalg
On Friday, 11 October 2013 at 16:10:21 UTC, FreeSlave wrote: There is Matrices and linear algebra module in wish list. Let's discuss its design. D is complicated language so it's difficult to choose the right way here. We need to find compromise between efficiency and convenient interface. I'm going to make some suggestions how this module should look like. Please, make your suggestions too. Firstly, my opinion is, it shouldn't be in the std package. Secondly, if it's not super highly performant, noone will use it. The highest performing linalg libraries implement the low level BLAS API or are vendor specific, like the Intel MKL. These are super optimized libraries where the asm code is hand optimized by specialists (GotoBLAS and the derived OpenBLAS for instance), and these will be *very* hard to beat. So much so that if BLAS isn't used as the engine, it's very unlikely that your library will be used for serious number crunching. Built above BLAS, you can find a number of libraries that make using linear algebra more pleasant. One such library, currently the best IMHO is Armadillo C++. It has the very big advantage that it mimics Matlab functions. This feature is extremely useful, because scientists very often model their algorithms in Matlab before porting them to C++. This is what is done in the company I work for. So the best I could suggest is to study the Armadillo C++ library and port it to D.
Re: Will Java go native?
On Thursday, 19 September 2013 at 23:37:05 UTC, Russel Winder wrote: I do note though that The Disruptor (by LMAX) is a seriously cool lock free ring buffer based system written entirely in Java. The Apache Cassandra distributed database is using it in its latest incarnation, among other things.
Re: Move VisualD to github/d-programming-language ?
On Saturday, 7 September 2013 at 19:26:11 UTC, Peter Alexander wrote: On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote: Recent threads here have made it pretty clear that VisualD is a critical piece of D infrastructure. Then it should be here: http://dlang.org/download.html That's the most important change that needs to be made. +1
Re: Had another 48hr game jam this weekend...
On Sunday, 1 September 2013 at 19:44:11 UTC, Brian Schott wrote: On Sunday, 1 September 2013 at 18:36:39 UTC, SomeDude wrote: I think at this point, what D needs is a bit of commercial support from a company like JetBrains or some equivalent. Maybe there is now an opportunity for founding such a company, one that would specialize in building professional tools around the D language. I believe the language and the compilers are stable enough to grow a serious business around them. If we compare to what the state of C++ compilers was before 2000, I believe we are much better off. And that was just over a decade ago. Who knows what the state of D will be in 5 years ? So yes, there is a case to be made for growing a company around pro D tools, and the first company that does it will grab the whole market. It's a bit of a chicken-and-egg problem. I'd like to do this, but there would have to be several companies already using D professionally for it to be a viable business model. And for a company to invest in D, they'd probably want the tooling to already exist. Your concern is legitimate of course, but there has been historically many cases where small companies have created a market in IT. There is clearly a demand for D tooling even if it's not huge right now, so I believe the risk is not as great as you think. Of course one needs some good skills to be able to come up with usable tools. But when nearly every D newcomer's first question is where are the tools ?, there is a market for that.
Re: Had another 48hr game jam this weekend...
On Monday, 2 September 2013 at 17:54:01 UTC, Dicebot wrote: On Monday, 2 September 2013 at 17:39:45 UTC, Joakim wrote: ... There is crucial difference between having a company providing commercial services for D users (good) and having anything closed/commercial in reference implementation (bad). Former is simply matching the demand from certain market segment. Latter is screwing the life for everyone else. There is hardly anything common here. Wait, I do not advocate building a closed source or non free reference implementation of the compiler or of the standard library. Those need to stay open source of course. But there are plenty of pro quality tools that are sorely missing right now: - an IDE that works with any of the 3 existing compilers - an integrated debugger - a graphical memory usage viewer/analyzer - a visual profiler - an integrated package manager - maybe a GUI library Etc. The existence of such tools would be a very big incentive for companies to try D seriously.
Re: Had another 48hr game jam this weekend...
On Sunday, 1 September 2013 at 13:20:50 UTC, Manu wrote: Why complicate the issue? What's wrong with readable code? Well, the fact is, AFAIK, it's never been an issue for C# and Java programmers. In fact, it' the first time I hear about people complaining on this one. Maybe because of the generalized usage of IDEs, I guess. I do agree that IDEs DO matter. It really does make a monumental difference. Without them, Java and C# programming would be a chore. But with them, you are often more productive than in Python (opinion based on my own professionnal experience). The problem is, maintaining one or several IDE plugins is going to be nearly a full-time job, even if the compiler is a library. Or you need a very motivated person like Iain Buclain to keep updating the tools. I think at this point, what D needs is a bit of commercial support from a company like JetBrains or some equivalent. Maybe there is now an opportunity for founding such a company, one that would specialize in building professional tools around the D language. I believe the language and the compilers are stable enough to grow a serious business around them. If we compare to what the state of C++ compilers was before 2000, I believe we are much better off. And that was just over a decade ago. Who knows what the state of D will be in 5 years ? So yes, there is a case to be made for growing a company around pro D tools, and the first company that does it will grab the whole market.
Re: std.logger
On Thursday, 22 August 2013 at 22:01:09 UTC, Jonathan M Davis wrote: On Thursday, August 22, 2013 23:36:48 David Nadlinger wrote: On Thursday, 22 August 2013 at 15:51:53 UTC, Craig Dillabaugh wrote: Do you really find the three extra characters a big problem. They are unnecessary. If you want to make clear you are dealing with logging, you can just write something along the lines of: import log = std.logger; log.error(123); I'd oppose warning, critical, error, etc. because they're not verbs like functions are supposed to be. It's variables or properties which are nouns. So, while I agree that the module system makes it so that the name clashes shouldn't be a big deal, I disagree with the names anyway and would still prefer logWarning to warning. - Jonathan M Davis OTOH, they are used in just about every logging API ever devised. Everybody knows what they mean. I just don't see the need to reinvent these words and make them longer by adding log. I seriously hate it. It clutters code (once you've read your thousand's log instruction, it hurts), adds ugly and useless redundancy and nothing else to its understanding. This alone is far worse than not using verbs.
Re: Article: Increasing the D Compiler Speed by Over 75%
On Friday, 26 July 2013 at 00:08:21 UTC, Leandro Lucarella wrote: Walter Bright, el 25 de July a las 14:27 me escribiste: On 7/25/2013 11:49 AM, Dmitry S wrote: I am also confused by the numbers. What I see at the end of the article is 21.56 seconds, and the latest development version does it in 12.19, which is really a 43% improvement. (Which is really great too.) 21.56/12.19 is 1.77, i.e. a 75% improvement in speed. This is certainly misleading, is very easy to be confused with a time reduction of 75%, which one would expect to be 1/4 of the original time. :) No, a division by 4 of the total time would be a 300% improvement in speed. The article's title looks correct to me.
Re: A proper language comparison...
On Thursday, 25 July 2013 at 20:03:52 UTC, Peter Alexander wrote: The problem is all those last bits: - Line counts aren't a good measure of anything. That's why some people prefer to compare a gzipped version of the source code. The gzipped version gives a more fair account of the code size.
Re: Flame bait: D vs. Rust vs. Go Benchmarking
On Friday, 26 July 2013 at 04:58:06 UTC, Nick Sabalausky wrote: It's either an overreaction to the quotes, or it's whitewashing reality itself. There's nothing else in those quotes to take issue with unless we're so very immature that we can't even handle the word crap. Or maybe it's simply because the rules 4, 5 and 6 (or whatever) of their community simply forbids such behavior, even if only very mildly offensive. I believe the moderator wants to keep good relations with other communities and not look like of a bunch of sectar fanboys.
Re: Flame bait: D vs. Rust vs. Go Benchmarking
On Friday, 26 July 2013 at 17:09:50 UTC, Jesse Phillips wrote: I'm not of the opinion this community needs a code of conduct. This group has many examples of harsh language both directed at code/projects and people. It results in community members to speak up against that language use, which is great, but we don't need Andrei and Walter stepping in and pointing out violation of rules. I agree.
Re: Flame bait: D vs. Rust vs. Go Benchmarking
On Wednesday, 24 July 2013 at 06:20:11 UTC, Andrei Alexandrescu wrote: On 7/23/13 9:23 PM, Walter Bright wrote: reddit link: http://www.reddit.com/r/programming/comments/1ixnf6/benchmarking_roguelike_level_generation_go_rust/ Please post your comment here to Reddit! Did. I tried to provide positive feedback. I'm mildly miffed how the text is so much at odds with the numbers - literally as if the text was written beforehand and the numbers collected at the last minute. Andrei Whatever miffs us, let's try to keep cool and show the same class that the Rust guys do here: https://mail.mozilla.org/pipermail/rust-dev/2013-July/004838.html Oh, and BTW, I really want to congrat them, they've been doing a great job so far.
Re: Flame bait: D vs. Rust vs. Go Benchmarking
On Friday, 26 July 2013 at 01:48:36 UTC, Nick Sabalausky wrote: On Fri, 26 Jul 2013 01:14:42 +0200 Not to slam Rust or the Rust people, but I wouldn't call that an example of class so much as new age nazi: where everything is incontrovertibly wonderful in it's own special way and any opinion contrary to that is categorically invalid and not to be tolerated (or must, at least, be first run through a rose-tinted castration filter). Referring to those two quotations as throw[ing] random slander is outright hyperbole and very much an overreaction. I'm *very* glad that we've been mature enough here to allow real, frank discussion and not descend into the self-righteous, almost Orwellian, whitewash trap of happy...or else. new age nazi, castration filter, almost orwellian... talk about overreaction. I think the intent of the moderator is to keep the level of discussions high,and have some not to rose-tint them. I expect the main leaders of the D community to keep the same high standards, not only on the m-l, but also on other forums and bulletin boards, like reddit or HN. After all, it's important to show that we all keep an open mind.
Re: Flame bait: D vs. Rust vs. Go Benchmarking
On Friday, 26 July 2013 at 03:37:46 UTC, SomeDude wrote: On Friday, 26 July 2013 at 01:48:36 UTC, Nick Sabalausky wrote: On Fri, 26 Jul 2013 01:14:42 +0200 Not to slam Rust or the Rust people, but I wouldn't call that an example of class so much as new age nazi: where everything is incontrovertibly wonderful in it's own special way and any opinion contrary to that is categorically invalid and not to be tolerated (or must, at least, be first run through a rose-tinted castration filter). Referring to those two quotations as throw[ing] random slander is outright hyperbole and very much an overreaction. I'm *very* glad that we've been mature enough here to allow real, frank discussion and not descend into the self-righteous, almost Orwellian, whitewash trap of happy...or else. new age nazi, castration filter, almost orwellian... talk about overreaction. I think the intent of the moderator is to keep the level of discussions high,and have some not to rose-tint them. I expect the main leaders of the D community to keep the same high standards, not only on the m-l, but also on other forums and bulletin boards, like reddit or HN. After all, it's important to show that we all keep an open mind. BTW, this post I saw on reddit and has been very well received. http://www.reddit.com/r/programming/comments/1iydil/the_zed_shaw_phenomenon_a_look_at_bullies_in_tech/cb9berc
Re: [OT] Why mobile web apps are slow
On Wednesday, 10 July 2013 at 17:25:31 UTC, Sean Kelly wrote: On Jul 9, 2013, at 11:12 AM, Paulo Pinto pj...@progtools.org wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Oh, regarding ObjC (and I'll qualify this by saying that I'm not an ObjC programmer). My understanding is that ObjC was originally reference counted (ARC = Automatic Reference Counting). Apple then introduced a mark sweep GC for ObjC and then in the following release deprecated it and switched back to ARC for reasons I don't recall. However, reference counting *is* garbage collection, despite what that slide suggests. It just behaves in a manner that tends to spread the load out more evenly across the application lifetime. C++ has gone te ARC route as well with shared_ptr. I find the scoped_ptr/shared_ptr combination quite convenient and quite safe overall.
Re: SIMD on Windows
On Saturday, 22 June 2013 at 16:04:26 UTC, jerro wrote: I have actually run that benchmark with the code from this branch: https://github.com/jerro/pfft/tree/experimental Hello, did you propose your pfft library as a replacement in std.numeric ?
Re: D repl
On Sunday, 30 June 2013 at 13:31:02 UTC, bearophile wrote: cal: I uploaded a small demo of a D repl i've been playing with, In past I have seen D repls, they come and then they fade away, regardless how much work they have required to be created, or how much refined they are. The fact they have appeared more than once shows some persons desire them. Yet, I see no comments from Walter or Andrei. I think a repl needs to be inside the standard D distribution, it's not an external toy meant to be forgotten, it's one essential tool for D development, like a profiler, debugger, or rdmd :-) Bye, bearophile It's cool, but it's yet another tool to maintain. Thus their lack of enthusiasm I guess. Unless someone comes forward and is ready to maintain the repl, in which case I think everyone would applaud.
Re: D repl
On Sunday, 30 June 2013 at 15:35:11 UTC, bearophile wrote: SomeDude: It's cool, but it's yet another tool to maintain. Thus their lack of enthusiasm I guess. Unless someone comes forward and is ready to maintain the repl, in which case I think everyone would applaud. I understand and I agree, thank you for putting me back on the ground. Sorry for that. ;) I just saw the video and it looks really awesome indeed. Also, I remember that today they add things to the Python standard library only when they are already widely used (unless they are created by people like Hettinger). So maybe it's better to see one D repl used a lot in the wild a lot, and only then add it to the standard distribution. Bye, bearophile Yeah, it probably needs a little testing before being included once for all.
Re: D vs C++ - Where are the benchmarks?
On Sunday, 30 June 2013 at 19:48:45 UTC, Gabi wrote: Hi D community, I am new to D and got impressed with the language so much that I was thinking on introducing D it my workplace as an alternative to C++ which is heavily used on our projects. The first question that came up was how it stands up with C++ performance wise ? I didn't find D on the shootout site (why?) and didn't find almost any benchmarks comparisons. Are there any good comparisons out there ? Gabi D used to be in the shootout, and was doing very good, right on par with g++. That was before Isaac Gouy, the maintainer of the shootout/benchmark game, decided to remove a number of languages, among which D. Don't ask us what his criteria are, noone knows for sure. Overall, the performance of D can be extremely good. It is most often largely superior to Java, and it can even be better than C++ in non trivial programs, if one cares about not allocating too much on the heap. It seems indeed that the automatic memory management is a major performance killer, and it's not always easy to know in advance what the overall performance of D code will be. But the less work for the GC, the better. To illustrate this, in one recent thread, one guy did a direct translation of his C++ raytracer to D. His first attempt wasn't very good, as the D version was almost 10x slower than the C++ version (with the same gcc backend), which is abnormal. A few simple optimizations later (without changing the algorithm), the D version was 40% faster than the g++ -O2 version. Another example of high performance is the std.regex library, which is known to be faster than all other implementations that we've heard of, in any language. So yes, one can get stellar performance out of D, but I would say right out of the box, it's not automatic, it does require some work where high performance is needed. However, out of all the existing languages, it's probably second only to C++. Up until fairly recently, memory allocation was not considered a primary concern, so that some parts of the Phobos standard library do allocate memory behind the scene. But today, a lot of attention is being paid not to allocate when it's not absolutely necessary, and the standard library is slowly being expurged of unnecessary allocations. This is largely a manual process, though. In a not too distant future (say before 2014), some tooling will help detecting spurious memory allocations, so that there is good hope that the Phobos library will be essentially clean in that regard. Also, there is some work going on for a concurrent GC.
Re: D vs C++ - Where are the benchmarks?
On Sunday, 30 June 2013 at 20:47:17 UTC, Adam D. Ruppe wrote: On Sunday, 30 June 2013 at 20:37:16 UTC, SomeDude wrote: It seems indeed that the automatic memory management is a major performance killer Eh, I'd say it is D's gc implementation specifically that is the biggest worry rather than the concept. I think the .net gc is seriously like 10x faster than D's implementation. Yes, yes, you're right. However, not allocating at least in Phobos is one of the surest way to get near optimal performance, not to mention it's always more satisfying when you know that your program doesn't monopolize Mb of RAM to do even the simplest task.
Re: top time wasters in DMD, as reported by gprof
On Monday, 24 June 2013 at 16:46:51 UTC, dennis luehring wrote: so it could be std library implementation related - can DMC use the msvc libs? (just for the compare) and you should also try 2010 - or better 2012 msvc (it still gets speedier code out) Is there still a free version of the VS compiler ?
Re: top time wasters in DMD, as reported by gprof
On Wednesday, 26 June 2013 at 05:39:00 UTC, SomeDude wrote: On Monday, 24 June 2013 at 16:46:51 UTC, dennis luehring wrote: so it could be std library implementation related - can DMC use the msvc libs? (just for the compare) and you should also try 2010 - or better 2012 msvc (it still gets speedier code out) Is there still a free version of the VS compiler ? Ah yes, Visual Studio Express 2012 is free.
Re: [Phoronix] D Language Still Showing Promise, Advancements
On Friday, 21 June 2013 at 11:13:49 UTC, Paulo Pinto wrote: It all depends what Mozilla and Samsung do with the language. If you have powerful entities pushing a language down developers throats, it will get used. That is how many mainstream languages got where they are now. -- Paulo I wonder why hasn't any *big* corp backed up D so far.
Another company using D
Just viewed on reddit: –]peterlundgren 6 points 10 heures de ça I keep getting more and more jealous of the few developers out there who are getting paid to write software in D. perma-liensignalergive goldrépondre [–]MrJNewt 7 points 10 heures de ça I write D all day at Economic Modeling Specialists (www.economicmodeling.com) and we're always interested in resumes from experienced developers who know or want to learn D. I wonder how many companies are using the language in production right now. Should we start a page They're using D somewhere ?
Re: Another company using D
On Saturday, 15 June 2013 at 08:04:08 UTC, SomeDude wrote: Just viewed on reddit: Forgot: http://www.reddit.com/r/programming/comments/1gbu3c/dconf_2013_dspecific_design_patterns_by_david/ (super interesting talk BTW)
Re: Effective D book?
On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote: Heck, to throw something out there, why not D Best Practices? Or D Patterns and Practices ? With some David Simcha content in it (if he agrees with that of course).
Re: Formal Review Process
On Tuesday, 11 June 2013 at 13:55:31 UTC, Jesse Phillips wrote: On Tuesday, 11 June 2013 at 03:36:23 UTC, Jonathan M Davis wrote: The whole _point_ of an official review is to review the API that would end up in Phobos (the implementation is also important but very much secondary). Then what are you complaining about? If a submission's API isn't ready to be merged into Phobos assuming that it passed the vote, then it isn't ready for review. The whole point of an official review is to decided if the API is ready to be merged into Phobos. A review manager can't make that decision, he brings it to the community and has them decided, Is this API what we would like to see for handling ? and the community votes yes or no. Nope. The whole point of a review process is to see if it can be *accepted* into Phobos. That is to say, it's already merged and mostly debugged. You can call your process whatever you want, but it's *not* a formal review process. It's more like a RFC.
Re: User Defined Attributes (UDA) in Phobos/druntime
On Wednesday, 12 June 2013 at 07:46:31 UTC, deadalnix wrote: On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote: On 6/11/2013 12:00 AM, Jacob Carlborg wrote: Thoughts? I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions. That sound good, but the complete opposite have been done every single time. That raise the question of consistency. And that's why Walter wants to avoid repeating the same mistakes again.
Re: std.compress
On Thursday, 6 June 2013 at 14:26:51 UTC, Peter Alexander wrote: Modules are for grouping functions/types that are commonly used together or have interdependencies, not for grouping things that are in a similar category (although these things can be related). I don't care if levenshteinDistance is a classic algorithm, I don't want to have to compile it every time I want to take the minimum of two numbers. Barely anyone is ever going to use it, so it should be off in a module on its own. There's absolutely nothing wrong with having lots of small modules provided that you don't end up importing the same sets of modules over and over. There are numerous advantages: 1. Makes it easier to manage dependencies. 1a. reduces compile times. 1b. reduces binary size. 1c. benefits incremental and distributed/parallel compilation. 2. Makes version control easier as more files means merge conflicts are less likely. 3. Makes it easier to navigate files. The only downside is that you may occasionally have to import more modules. Wise words !
Re: Suggestion - use local imports in Phobos
On Tuesday, 4 June 2013 at 22:43:12 UTC, Andrei Alexandrescu wrote: One question would be where the right balance is, and how to make sure we strike it. Andrei I would say the principle of least surprise could be used here. i.e you may not be totally surprised to have a dependency upon the gzip module in an http module, but you don't really expect to have a dependency upon LevenshteinDistance, for instance.
Re: The stately := operator feature proposal
On Thursday, 30 May 2013 at 19:11:10 UTC, MrzlganeE wrote: And the alternative: x, y, z := f(), g(), h(); Right, now you want to add Python features to D. Why don't you design your own language instead ?
Re: The stately := operator feature proposal
On Thursday, 30 May 2013 at 11:41:34 UTC, MrzlganeE wrote: To me, 'auto' has a price. The price is a foreign word being inserted into my math. It's an invasive term. It ruins the beautiful expression. And tomorrow, you'll complain that := has a foreign character into your math, because everywhere else, you use = and there is no reason for the first equal sign to add : in front of it.
Re: DConf 2013 Day 2 Talk 5: A Precise Garbage Collector for D by Rainer Schütze
On Wednesday, 5 June 2013 at 14:14:45 UTC, bearophile wrote: Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/1fpw2r/dconf_2013_day_2_talk_5_a_precise_garbage/ Is this useful to make the GC precise regarding the stack too? http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5570 Bye, bearophile Here is the blog post deadalnix is referring about at the very end of the video: http://www.deadalnix.me/2012/03/05/impact-of-64bits-vs-32bits-when-using-non-precise-gc/
Re: std.compress
On Wednesday, 5 June 2013 at 18:36:34 UTC, David Nadlinger wrote: It also doesn't utilize template constraints, reinvents isRandomAccessRange hasSlicing under a poor name, uses C printf (!) in the examples, has random 2-3 letter variable names (dis, dip, di, si) all over the place, … David Walter explained that calling printf allowed him not to import half of std. I think it's a good practice to limit dependencies to a reasonable minimum. Of course, it's hard to come up with a general rule as to what reasonable means here.
Re: std.compress
On Wednesday, 5 June 2013 at 07:00:14 UTC, Jonathan M Davis wrote: So, you want to create whole modules for each compression algorithm? That seems like overkill to me. What Walter currently has isn't even 1000 lines long (and that's including the CircularBuffer helper struct). Splitting it up like that seems like over-modularation to me. - Jonathan M Daivs Well, as the author of a 15,000 lines datetime module, I think your opinion is a little biased. *I* think 1,000 lines is a perfect size for a module.
Re: std.compress
On Wednesday, 5 June 2013 at 22:06:09 UTC, Adam D. Ruppe wrote: you know it might be a decent idea to change std.stdio to use scoped imports and have the writeln that specializes on string to not import anything else and see what happens on the hello world case. I think using scoped import should be a requirement in the standard library.
Re: Time to destroy Walter: breaking modules into packages
On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote: But I believe that package level access only works on the same level, so you couldn't have separate modules for compressing and decompressing as was being suggested. It would need to be more like std.compress.zlib; std.compress.lzw; At that point, it would be trivial to have a common module of some kind with shared functionality which has package access level. - Jonathan M Davis +1 That seems to be the right level of granularity.
Re: Slow performance compared to C++, ideas?
On Sunday, 2 June 2013 at 14:34:43 UTC, Manu wrote: Yeah, this is an interesting point. These friends of mine all write C code, not even C++. Maybe you should mention to them Julia. It's quite a good scientific language.
Re: hello world in D
On Friday, 31 May 2013 at 16:31:42 UTC, Regan Heath wrote: Do you really think that is such a big issue? Not really an issue, no. But newcomers keep creating threads like this one time and again and who knows how many have been turned away without finding out the whys and wherefores. R Maybe it's a question that could be addressed through the wiki then ?
Re: The non allocating D subset
On Saturday, 1 June 2013 at 16:02:06 UTC, Paulo Pinto wrote: I get the feeling it starts to feel like Ada then. :) Adam starts with Ada !
The non allocating D subset
In the Rust based provocation thread, I think Adam Ruppe's work went largely overlooked. He basically created a minimal D that runs on bare metal, proving thus that D can be used fruitfully on small embedded devices in place of C. On Monday, 27 May 2013 at 15:45:04 UTC, Adam D. Ruppe wrote: On Monday, 27 May 2013 at 14:36:59 UTC, Dicebot wrote: But issue is not creating minimal run-time, it is creating minimal one that still has most part of language usable. eh the question is what is most? Even my little 200 line thing has: functions, templates, scope closures, structs including operator overloading, static arrays, slices, pointers, __traits+ctfe, scope guards, switches, and more. I just now added basic classes and that wasn't too hard (copy/pasted some code from the real druntime for the typeinfo and so on). But it doesn't do AAs, throwing exceptions, dynamic arrays and other nice features. Looking at druntime's src, exceptions look hard, and while dynamic arrays, heap closures, and others can easily 'work', they will leak memory, so I don't think they will ever be really good without gc. Exceptions are doable though from what I can tell. Anyway I think this is enough to do some real programs and feel kinda nice. Surely no worse than C at least. This is already a great proof of concept in my opinion. But more than that, I believe that this minimal D is the sublanguage that could prove useful to game programmers in place of C++. Basically it is a non allocating D subset. It retains most of the niceties of D without ever resorting to the GC, so it's a definite improvement over C++. There is absolutely no reason performance would suffer from programming in this D sublanguage. The only real hassle being one still has to do manual memory management, but users of such a subset are used to that and prefer to do it themselves than using a GC anyways. Following this idea, I believe a fairly large chunk of Phobos could be ported to compile with this minimal D sublanguage, and that one could use the allocating D and its added sugar on top of it. So in the end, the user could decide between working with the non allocating language (mostly embedded programmers and game makers), or benefit from the GC and all the associated niceties (the rest of us). This would make D the truely universal language it was intended to be.
Re: The non allocating D subset
On Saturday, 1 June 2013 at 05:45:38 UTC, SomeDude wrote: This would make D the truely universal language it was intended to be. This is a large undertaking, but I think there is no technical hurdle preventing it to succeed. IBasically it's only a matter of sweat. In fact I believe it has a much better chance of success than having a GC that solves all the problems, as we know that even after Sun and Microsoft have poured in thousands of hours of brainpower in engineering, the GC is never good enough for all purposes.
Re: Garbage collection, and practical strategies to avoid allocation
On Saturday, 1 June 2013 at 02:03:07 UTC, Manu wrote: So let's talk about garbage collection, and practical strategies to avoid allocation. Discuss... (or perhaps, destroooy) Here is my take: http://forum.dlang.org/post/tftjtzmfuauxwcgco...@forum.dlang.org Sorry, I didn't see your new discussion.
Re: Shameless autopromotion : type safe tagged union in D
On Friday, 10 May 2013 at 19:23:45 UTC, Jesse Phillips wrote: On Friday, 10 May 2013 at 17:56:14 UTC, Andrei Alexandrescu wrote: A general note about posting to reddit: it often happens that posts from infrequent posters go to spam by means of some automatic rule. When that happens you need to message the moderators and politely ask them to manually instate the post because it's legit. Once you accumulate karma and all, your posts will be auto-approved. Well that is stupid. It would be like StackOverflow closing questions of new users and waiting for people to vote to open. My submissions now all go to the spam section even though I have more than 1300 karma of comment and 800 karma of submission. It's fucking annoying.
Re: What is a pull request?
On Sunday, 12 May 2013 at 08:48:28 UTC, w0rp wrote: This thread is hilarious. This is like asking a car mechanic what an alternator is. Then when he gives you a handbook explaining what one is, you throw it back and spit fury in his face. Other people don't breathe to cater to your every whim, especially when you reject more than adequate explanations for questions. No, you are not clever. Aside from not being able to understand the simplest of things, you are not clever enough to speak to others with tact and respect. For this reason alone you should either re-evaluate the way you behave around others, or take a position which does not require teamwork. If you can't respond well to help, you cannot be expected to react accordingly when faced with the criticism you will surely face when making a pull request. Spare your saliva, it's the typical random troll. Probably the same drunk/lunatic guy coming over and over again in this newsgroup. I wonder if there are sociological studies of guys like that. I've yet to understand what their motivation is, if there is one.
Re: DConf 2013 Day 1 Talk 2: Copy and Move Semantics in D by Ali Cehreli
On Friday, 10 May 2013 at 15:24:43 UTC, Jacob Carlborg wrote: On 2013-05-10 16:38, Andrei Alexandrescu wrote: Two a week. Is there a reason for this? It's good to keep people busy with D. ;) There have been way to many Go posts on reddit lately. :D
Re: Stable D version?
On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote: On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote: On 4/23/13 2:42 PM, eles wrote: On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu I was mainly referring to the fact that C++ succeeded in spite of having initially an incomplete specification. Nowadays the expectations are much higher. Andrei As long as you keep changing the language, no specification will ever be complete. C++ will long advance. D must be out and living before C++14. Then, it will be too late. My view. I also think when modules are integrated into the C++ standard, for most developers, there won't be any case left for D. Even though D technically is superior in almost every way, conservatism is strong enough.
