Re: Somewhat off-topic: Nemiver
On Friday, 13 February 2015 at 07:42:41 UTC, weaselcat wrote: On Thursday, 12 February 2015 at 23:18:29 UTC, Brian Schott wrote: I've been looking for a graphical front-end for GDB that's not terrible, and I've found that Nemiver works pretty well. It's worth trying out if you're on Linux. https://wiki.gnome.org/Apps/Nemiver/Features Nemiver works perfectly with D, is dead simple to use, and is probably one of the best debuggers(frontend, anyways) around IMO. I was using Nemiver because it just worked really well with D. Another great GDB frontend, especially for vim users is CGDB. Cheers, uri
Re: Should we remove int[$] before 2.067?
On Sunday, 1 February 2015 at 15:36:04 UTC, Andrei Alexandrescu wrote: On 2/1/15 2:00 AM, uri wrote: On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote: Whatever, anyway. Translation of that being: "Boring pedestrian issues like simple string logging are bikeshedded for YEARS, yet PhD-level esoteric stuff makes it into phobos with relative ease." https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md cautios and determination, isn't? or, revolutionary and conservative, how I did put it... +1 At least decisions are finally being made on several fronts recently though. W.r.t this feature, I was personally looking forward to it ... guess I'll stick with the Octave/R/Python "troika" for rapid protoyping numerical analysis code. Which feature are you referring to? -- Andrei int[$] a=[1,2,3]; The syntax sugar helps when prototyping ideas, which is why R and Octave (MATLAB) are so useful. I have reservations about this: auto a=[1,2,3].s Because the type is hidden from the programmer... For my use case (prototyping code) it's a don't care but in production code it might be a problem, as others have pointed out already. I actually use this trick already in my own code for malloc'd arrays to avoid the GC and add sugar to toStringz. All in all it is great to see some decisions been made. I think it will help shut down bike shedding and get D moving forward at a faster rate. Cheers uri
Re: Should we remove int[$] before 2.067?
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote: Whatever, anyway. Translation of that being: "Boring pedestrian issues like simple string logging are bikeshedded for YEARS, yet PhD-level esoteric stuff makes it into phobos with relative ease." https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md cautios and determination, isn't? or, revolutionary and conservative, how I did put it... +1 At least decisions are finally being made on several fronts recently though. W.r.t this feature, I was personally looking forward to it ... guess I'll stick with the Octave/R/Python "troika" for rapid protoyping numerical analysis code.
Re: accept @pure @nothrow @return attributes
On Tuesday, 27 January 2015 at 04:10:24 UTC, Andrei Alexandrescu wrote: On 1/26/15 7:25 PM, Zach the Mystic wrote: On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote: On 1/26/2015 6:15 PM, Zach the Mystic wrote: What's keeping you from committing to 'dfix' as the way to solve issues like the one in this thread? Inertia of people being reluctant to use it. It's still work for people to use, it's not part of their build process. What about compiler integration? I'm talking about fundamental language changes. Why would people use it if it didn't have official backing and wasn't part of the compiler package? In this post: http://forum.dlang.org/post/uimpnhiweuitnnbeq...@forum.dlang.org ... I said: 'For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: `@nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature.' That's what I mean by "commiting to dfix." I'm ready to commit to dfix. Problem is many of the changes suggested are unlikely to mark much improvement, while miring us in the perpetual illusion of making progress. The fact that we can avail ourselves of a tactical tool that makes changes easy is helpful but also opens opportunity of abuse. Let's stop shuffling the deck. I mean it. Stop shuffling the freaking deck. Fix the real issues in the language. Add new libraries. Be original. Be creative. Do real work. Thanks, Andrei Well said. I've been wavering for a few months between D and Python for teams on smaller internal projects. IMO this is the right attitude from core D devs to finish off D2. Cheers, uri
Re: One area where D has the edge
On Monday, 26 January 2015 at 22:53:15 UTC, Paulo Pinto wrote: On Monday, 26 January 2015 at 22:12:24 UTC, Laeeth Isharc wrote: " If Java consumes 15% more power doing it, does it matter on a PC? Most people don't dare. Does it matter for small-scale server environments? Maybe not. Does it matter when you deploy Hadoop on a 10,000 node cluster, and the holistic inefficiency (multiple things running concurrently) goes to 30%? Ask the people who sign the checks for the power bill. Unfortunately, inefficiency scales really well. No, Java does not consume 15% doing it, because there isn't just one implementation of Java compilers. Most comercial JVMs do offer the capability of ahead of time native code compilation or JIT caches. So when those 15% really matter, enterprises do shell out the money for such JVMs. Oracle commercial JVM and the OpenJDK are just the reference implementation. Thanks for the colour. (For clarity, the content from the link wasn't by me, and I meant the general gist rather than the details). How do commercial JVMs rate in terms of memory usage against thoughtful native (D) code implementations? Is the basic point mistaken? So far I just dabbled in D, because our customers choose the platforms, not we. However, these are the kind of tools you get to analyse performance in commercial JVMs, http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html http://www.oracle.com/technetwork/server-storage/solarisstudio/features/performance-analyzer-2292312.html Just providing the examples from Oracle, other vendors have similar tools. With them, you can drill down the whole JVM and interactions at the OS level and find performance bottlecks all the way down to generated Assembly code. As for memory usage, Atego JVMs run in quite memory constrained devices. Here is the tiniest of them, http://www.atego.com/products/atego-perc-ultra/ -- Paulo There was also this one from 1998 that was very small http://www.javaworld.com/article/2076641/learn-java/an-introduction-to-the-java-ring.html Java has some history running on small devices. Cheers, uri
Re: accept @pure @nothrow @return attributes
On Tuesday, 27 January 2015 at 01:32:23 UTC, Mike wrote:
On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:
On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
Personally, I'd much prefer that we not make this change.
It's good to have this discussion.
Previously, it's all been advocacy and "break my code" by
forcing a change from pure => @pure.
Yes, please! (at least about the "break my code" part)
Just a few days ago on slashdot, an anonymous D user wrote:
"A horrible mix of keywords and annotation syntax for
function/method
attributes ('const', 'pure', and 'nothrow' are all keywords,
but
'@property', and '@nogc' are annotations)"
for why he won't use D anymore.
Not a deal-breaker for me, but I agree with the sentiment, and
I think it makes for a more professional language if such
inconsistencies are addressed.
Frankly, I think that is a great bikeshedding non-issue that
distracts us from what is important.
Yes, there is no correlation between what's important, and what
people choose to work on, because there is no consensus on
what's important, and if there is it's usually beyond the
ability of most contributors, so it doesn't get worked on
anyway. Personally, I find small changes like this welcome
because they make for a more polished experience.
I hope that by doing this PR, we can actually decide that it
isn't worth it, i.e. I'd be happy to get consensus and revert
it.
A dangerous precedent. I suspect the push-back against this
change has probably ruined any chance of further polishing the
language.
From: https://issues.dlang.org/show_bug.cgi?id=13388#c27
***
I really think that we've passed the point where it's worth
fixing it.
NO This attitude is the biggest problem D has.
Please, watch Scott Meyer's talk again. "Most D code is yet to
be written".
The future benefits of fixing this kind of crap, are huge.
***
In fact, it is the attitude against change that has put me on
the fence about D, when I was quite an advocate about a year
ago. It has also made me reluctant to put forth the necessary
effort to study and make any significant contributions because
the controversy, as exhibited here, would likely erase my
entire investment. Instead, I have begun exploring other
options while keeping one foot on the raft.
I agree that, in general, D should take a more disciplined
approach to development, but keep in mind that if contributors
have to go through too much controversy and bureaucracy we're
not going to see much change (perhaps that's what some want).
I feel for Walter. He's damned if he does and damned if he
doesn't. Somehow, this herd of cats need to figure out where
it wants to go, and I need to figure out whether to go all in
or jump ship.
Mike
+1 to all of this as it mirrors exactly how I feel about D at
this point in time.
I get the impression it will never be finished because too many
are afraid of important breaking changes that seem necessary to
get through the last 5%-10% of D2.
Cheers,
uri
Re: An idea for commercial support for D
On Wednesday, 7 January 2015 at 02:16:47 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote: On 06/01/15 23:32, uri via Digitalmars-d wrote: The dmd backend is not under an OSS license, why haven't they left? I suspect there are not very many of the type of people you're talking about in the D community. It's possible that you're right but I don't see it happening. The backend doesn't provide any benefit to GDC and LDC and Walter has a very good reason for closing the backend sources which is understood by all. Small point: the DMD backend may not be released under a free software license, but it is not closed -- the source is available, development happens in the open, and in a de facto (rather than de jure) sense there is little to distinguish from an open source project. The licensing situation is obviously unfortunate, but it makes little practical difference considering that the vast majority of D language development is in the freely-licensed frontend, runtime or standard library, and there are two excellent free backends available. This is a pretty good example of what I have referred to elsewhere in this thread, about the contextual nature of objections to "non-free". Thanks for the correction, and a very important one at that in the context of this thread. I wasn't aware the backend was open source. Cheers, uri
Re: An idea for commercial support for D
On Tuesday, 6 January 2015 at 13:34:59 UTC, Joakim wrote: Before you make such claims, you should probably think about them a little bit first. Please tell me one company that does not buy outside commercial software which they then use to build their own products. Some companies will want to cherry pick features, others will just buy an accumulated patchset against the point release from many devs. The suggestion that all companies will have to spend a great deal of time picking what patches they want is just silly. To me it doesn't make sense for a company to cherry pick compiler patches. The model you propose may work for applications where there is a clean distinction between user needs and wants but in a compiler you generally need all the features to work effectively and produce reasonable code. The optimizer may be a different story so perhaps that aspect of compilation could be split. Besides splitting the compiler will result in a maintenance headache. Missing features in the compiler will not result in subset-D and complete-D but half-baked-nearly-working-D and working-D, if you're lucky. This means A and B can't make any money off their patches, so they have to get some other job. That means they only have time to work on M and X on the occasional weekend and each of those patches takes six months to finish. You are obviously okay with that glacial pace as long as you get their work for free, but others are willing to pay to get the pace of D development sped up. This is only true if all patches are equally priced. Otherwise it breaks down and has been proven mathematically. Glad you brought this up, there are several possibilities. Many users would probably just buy all the closed patches against a point release, so there is no question of splitting features. But a handful of paying customers may be more adventurous, or cheap, ;) and choose to only buy a custom build with their needed features X,Y,Z. This probably wouldn't happen right away, as it will take more time to setup a build process to support it, but supporting custom builds like that is definitely worthwhile. OK, but the D devs still need to split the release between paid patches and non-paid patches. This is non-trivial in a compiler and adds additional work for the volunteers. Companies won't pay for the split because it isn't value adding for them so it will fall on the volunteers. To begin with, D is not a GPL project, so why would they release them under the GPL? So we wait some time period for the patch to be released. As stated earlier, the patches would need to be funded up to some monetary and time limits before they would be released back to the OSS project. So party A might contract with their paying customers that they'll release patches X,Y,Z once they accumulate $5k in payments from all the customers who buy those patches, plus a six month delay after that. If they don't make $5k for a long time, the patches won't be released for a long time. Then I think most OSS users would move on to another language. There is no point working with a compiler that is half-baked unless you pay for it. This is an issue because it's the OSS community that provides ongoing maintenance to the paid for patches. If OSS isn't there anymore then Digital Mars needs to start charging maintenance costs to upkeep the codebase. I don't think that will work, but it's only my opinion. Why does anyone pay for software now? It doesn't much matter to a paying customer that the feature will probably be free in a year or two if they need to use it to make money _now_. But that's assuming an entity needs D to make money now. They don't because we have C++, Java, C# already. Why not just use one of those more mature languages? As for people leaving because somebody else has developed a proprietary feature for D and not given it to them for free, companies like Sociomantic have already developed such features and they haven't been integrated upstream, why haven't "most" left already? The features from Sociomantic features are all D1 and also there are devs from Sociomantic are trying to get features released upstream. Sociomantic isn't the blocker it's integrating the features into D2. The dmd backend is not under an OSS license, why haven't they left? I suspect there are not very many of the type of people you're talking about in the D community. It's possible that you're right but I don't see it happening. The backend doesn't provide any benefit to GDC and LDC and Walter has a very good reason for closing the backend sources which is understood by all. Maybe a handful of FOSS zealots would leave, but the resulting commercially supported D would be so much better, they'd be swamped by the new people coming on board. :) We'll see :) Cheers, uri
Re: An idea for commercial support for D
Hi, Your business model is flawed for a number of reasons. Firstly, companies make money from their own products, not paying staff to figure out which bug fixes/features to cherry pick for the tool chain. Secondly, no one makes money by locking out others when they themselves can be locked out in the same manner. This is basically what your model seems to boil down to. Party 'A' provides patches X,Y,Z in the compiler and others have to pay for them. Party 'B' provides patches M,N,O and similarly, others pay for them. Now party A does not benefit from M,N,O unless they pay for it and party B does not benefit from X,Y,Z unless they pay for it. So no one wins. So the best solution is A and B both open their patches and both benefit from all contributions. Thirdly, how can one separate the features? For example, say I'm willing to pay for features X,Y,Z but not M,N,O. How do the D devs split the features out so I only get M,N,O? Separate and special builds for each paying customer? Fourthly, what about the OSS people using D? Are the X,Y,Z and M,N,O features released GPL so they can benefit immediately or do they wait 6 months? If it's 6 months why would anyone pay for the features? If it's longer than 6 months, or even if its GPL I think most will abandon D and go to Nim or Rust. Cheers, uri
Re: Worst Phobos documentation evar!
On Sunday, 28 December 2014 at 15:57:39 UTC, Ary Borenszweig wrote: After programming in Ruby for a long time (and I think in Python it's the same) I came to the conclusion that all the sections (Return, Params, Example) just make writing the documentation a harder task. For example: ~~~ /* * Returns a lowered-case version of a string. * * Params: * - x: the string to be lowered case * Return: the string in lower cases */ string lowercase(string x) ~~~ It's kind of redundant. True, there might be something more to say about the parameters or the return value, but if you are reading the documentation then you might as well read a whole paragraph explaining everything about it. -1 Most of the time I know what the function does but I need the docs for the parameters and types. For example, this is the documentation for the String#downcase method in Ruby: ~~~ def downcase(str) Returns a copy of `str` with all uppercase letters replaced with their lowercase counterparts. The operation is locale insensitive—only characters “A” to “Z” are affected. Note: case replacement is effective only in ASCII region. "hEllO".downcase #=> "hello" ~~~ Note how the documentation directly mentions the parameters. There's also an example snippet there, that is denoted by indenting code (similar to Markdown). Again, I don't want to wade through a wall of text just to get the parameter types or what a function returns. The signature itself is too noise IMO so explicit Return & Param sections are preferable IMO. I'd also like to see TemplateParms: or TemplateTraits:, as others have already mentioned. I think it would be much better to use Markdown for the documentation, as it is so popular and easy to read (although not that easy to parse). DDoc is not hard to read or write so Markdown would be wasted effort. If DDoc generated Markdown that might be useful for the WIKI. Then it would be awesome if the documentation could be smarter, providing semi-automatic links. For example writing "#string.join" would create a link to that function in that module (the $(XREF ...) is very noisy and verbose). +1 I agree links to functions would be much simpler with a #tag. Cheers, uri
Re: Rectangular multidimensional arrays for D
On Tuesday, 23 December 2014 at 03:11:20 UTC, Laeeth Isharc wrote: On Monday, 22 December 2014 at 22:46:57 UTC, aldanor wrote: On Monday, 22 December 2014 at 22:36:16 UTC, H. S. Teoh via Digitalmars-d wrote: FYI, Kenji's merge has since been merged. So now the stage is set for somebody to step up and write a nice multidimensional array implementation. One important thing to wish for, in my opinion, is that the design of such implementation would allow for (future potential) integration with linear algebra libraries like blas/lapack without having to be rewritten from scratch (e.g. so it doesn't end up like Python's array module which got completely superceded by numpy). You mean especially for sparse matrices ? What is it that needs to be borne in mind for regular matrices ? The layout in lapck/blas is column major so it can be handy using a wrapper around arrays to provide the FORTRAN indexing. Also you need to pass the .ptr property of the array or &a[0]. D arrays are fat and include their length. Cheers, uri
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 12:53:32 UTC, Tobias Pankrath wrote: On Friday, 19 December 2014 at 12:44:26 UTC, Kiith-Sa wrote: On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright wrote: On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote: Docs need to have examples which are plain and obvious, and the language will be absorbed by osmosis. I agree. Can you point to specific cases that need an example? If it doesn't have an example, it needs an example, no matter how trivial it is. That's a good place to start. Of course, then there are lazy examples that don't really help in real use. These need to be identified and rewritten. • If you look up how to do $x in the documentation and it is takes you time to figure that out, consider to add an example for $x to the documentation. • If you answer/ask a question in D.learn on how to do $x, consider to add an example for $x to the documentation. This way we should build up exactly those examples that are useful. +1 No different to adding unit tests where possible for each reported bug.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 11:54:42 UTC, ketmar via Digitalmars-d wrote: On Fri, 19 Dec 2014 10:47:27 + Sergei Nosov via Digitalmars-d wrote: In the "debugger" case, Manu's point is that it's unusable. And Walter's implied point is "debuggers aren't that useful anyway, so why it was a showstopper?". My personal observation is that "excellent programmers" share the Walter's point on debuggers - they practically don't use it. And the uselessness is so obvious, that there's nothing even to talk about. At the same time, "good programmers" use it extensively, especially on Windows. It is so useful to them, that there's nothing even to talk about! one of the things one can do if he is in corresponding position is to ban debuggers. i found that after month or two people start producing better code with better documentation and "control knobs". and surprisingly faster. debugger is just a kind of bad habit, and when people faced the fact that they will not be payed for work simulation (and why should we?), they either go or becomes more productive. This is true. The first week for a new developer where I work is developing a better boot loader. The debugger is not allowed during this induction week and as a result our devs learn how to write better code first time through careful planning and understanding of what's going on at the machine level. Cheers, uri
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 09:52:09 UTC, uri wrote: On Friday, 19 December 2014 at 07:37:45 UTC, Dicebot wrote: On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote: me too. it's really disgusting how you guys treat (verbally mistreat) others, who take a chance with D. Good luck to you all on your pet project. And how? Explaining mistakes and reasons why just taking a chance brings nothing (and can as well do a harm)? Chris point was overblown, sure, but so was original post. Manu has explained his case in great details and that was very good. However it was missing single most important part - explanation of what he wants to achieve, what actions he expects from community. So far it sounded like "hey guys I know you are nerds so go implement everything I need for my projects instead of working on yours". I'd be glad to be mistaken but it still looks like that so far. +1 What D needs right now is for people to stop complaining about the things that are wrong and start contributing. Cheers, uri And if you don't have time to contribute then submit an ER or bug report. Even that will be more constructive than having a pubilc tantrum when others disagree. A bit embarrassing I'd say. Cheers, uri
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 07:37:45 UTC, Dicebot wrote: On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote: me too. it's really disgusting how you guys treat (verbally mistreat) others, who take a chance with D. Good luck to you all on your pet project. And how? Explaining mistakes and reasons why just taking a chance brings nothing (and can as well do a harm)? Chris point was overblown, sure, but so was original post. Manu has explained his case in great details and that was very good. However it was missing single most important part - explanation of what he wants to achieve, what actions he expects from community. So far it sounded like "hey guys I know you are nerds so go implement everything I need for my projects instead of working on yours". I'd be glad to be mistaken but it still looks like that so far. +1 What D needs right now is for people to stop complaining about the things that are wrong and start contributing. Cheers, uri
Re: Lost a new commercial user this week :(
On Tuesday, 16 December 2014 at 05:48:27 UTC, Rikki Cattermole wrote: On 16/12/2014 5:11 p.m., MattCoder wrote: On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole wrote: I started writing a small booklet on this, if you got an email if you're interested or some way to send you. Please let me know. Do you mind to share with us all? :) Matheus. https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing No guarantees of how long it'll stay up there. And to reiterate, its only just a start. And I don't know if I ever complete it. There isn't really enough material for an actual book. Maybe booklet but meh. This is a great start, keep going with it!! A book that looked at the details of CTFE with examples and comparison of patterns implemented in CTFE vs. RT would be a really nice addition to the D books already available.
Re: i want my bounty!
On Monday, 15 December 2014 at 09:31:28 UTC, ketmar via Digitalmars-d wrote: On Mon, 15 Dec 2014 09:07:53 + uri via Digitalmars-d wrote: You were looking forward to that, in fact I'd say trolling for it... that's not the first time i asking why bugzilla is still able to host patches. i just wanted to make myself sure that "any input is valuable" is blatant lies. one last time. OK, fair point. Your contribution is welcome and if you don't want to use Github, the chosen tool of D development, that's fine. But you cannot expect to dictate when others will turn your patches into PRs for you to get them into the D ecosystem. i.e. "shut the fuck off and get lost with your stupid patches, nobody is interested." this is not "welcome", this is "github or get lost". You'll just have to wait, unless you submit the PR yourself of course. i waited for several month for *any* reaction. as my past expirience shows, the only reliable way to make somebody look at bugzilla patches is to start trollfest here. but i'm tired of that. PS: You don't even have to join Github with your real name and email... i don't even understand why i have to join github in the first place. i don't want to be a part of github, i'm not interested in that. that's why i registered on official D bugzilla. Ideally there'd be a tool to turn Bugzilla patch submission into a Github PR. But again it's work *someone* has to do and it isn't *that* much of a hurdle to get onto Github with a made up account just for D. Cheers, uri.
Re: i want my bounty!
On Monday, 15 December 2014 at 08:54:24 UTC, ketmar via Digitalmars-d wrote: On Mon, 15 Dec 2014 13:19:01 +1100 Daniel Murphy via Digitalmars-d wrote: "ketmar via Digitalmars-d" wrote in message news:mailman.3160.1418550079.9932.digitalmar...@puremagic.com... > but talking seriously, i don't need any bounty, i just want > somebody to > take a look at that and either tell me what to fix or > integrate it in > mainline. along with this one: > https://issues.dlang.org/show_bug.cgi?id=13526 Review of patches for dmd are done on github: http://wiki.dlang.org/Pull_Requests#Create_a_pull_request so DON'T ALLOW THE FUCKIN' BUGZILLA TO HOST PATCHES! and stop pretending that D is normal open-source project where anyone can send patches. that's blatant lies. i can see why i have to register on D bugtracker, which has the address "issues.dlang.org". but i can't see why i must register on some 3rd-party site which has NOTHING in common with D. You were looking forward to that, in fact I'd say trolling for it... Your contribution is welcome and if you don't want to use Github, the chosen tool of D development, that's fine. But you cannot expect to dictate when others will turn your patches into PRs for you to get them into the D ecosystem. You'll just have to wait, unless you submit the PR yourself of course. Cheers, uri PS: You don't even have to join Github with your real name and email...
Re: Why do you write D2 compiler using C++ language?
On Sunday, 14 December 2014 at 16:44:09 UTC, ddj wrote: On Saturday, 13 December 2014 at 23:02:52 UTC, Mike Parker wrote: On 12/13/2014 10:55 PM, ddj wrote: But so many issues and bug fixes scares me from using it. That's just the wrong way to look at it. Take a look at the bug list for gcc, any of the Java compilers, or clang. Are you afraid to use them as well? Maybe, but gcc and java compilers have long history of stable releases and many programs and libraries written. Clang has standards to implement and! static analyzer. As Mike said, look at the bug tracker history for these projects. Even with all those stable releases there were always lots of open bugs and today in GCC 4.9 there are issues: http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00650.html We use GCC 4.8 at my work where we develop class II and class III health-care devices - A life support system is class III...how well do you trust GCC? :-). Joking aside we design for failure and have a 4 year verification process that weeds out critical bugs in our code and the compiler. Cheers, uri
Re: Lost a new commercial user this week :(
On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote: On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote: As always, different tools for different uses. Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :) when will that be? windows version 25, sqlite version 1147? ...[snip]... Perhaps when more people start helping out we'll see things progress more quickly. D needs more than developers. Right now it needs a few volunteers who will update the web site; documentation, news feeds of recent PRs closed, recent PRs that are generating interesting discussion, roadmaps for the next 12 months indicating what core devs are working and status. Stuff that get's people excited about the next release and the future of D. Cheers, uri
Re: D game development: a call to action
On Saturday, 13 December 2014 at 22:49:10 UTC, Joel wrote: On Tuesday, 6 August 2013 at 06:23:09 UTC, qznc wrote: On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap wrote: I am one of the few who have taken a keen interest in D for game development. The concise language and modern conveniences may be able to reduce many hours worth of development time off a game project, while making the code more maintainable. Aside from the core language, Dlang graphics bindings have a way to go before even earning acceptance in the indie gaming scene, but it's making great strides to get there. The main challenge I've hit is the lack of any sort of path for adopting a media engine. Bindings (like SFML https://github.com/krzat/SFML-D) all suffer from: A) No information about its current status: this is scary if its repo hasn't been updated in months. B) Usually are complex to get working in a new project (manually building or searching for undocumented dependency DLLs) C) Lack practical references and tutorials for "real would usage" e.g. "how to create an OpenGL window" or "how to render a triangle" versus something like "how to load from disk an image texture onto a quad and move it around using keyboard events" SFML bindings are also in https://github.com/aldacron/Derelict3 but I couldn't find a scrap of information on how to use it, how to compile correctly, or example usage. It's unclear if the library is even usable in its current state. Please don't take this as blind criticism, but rather a plea to action for the community to provide better library documentation support for: current lib status, getting started adding it, and a general use tutorial/example. If we start doing this, it'll make a big impact for other game developers who are new to Dlang to adopt the language. Thanks for listening! I am using DAllegro 5 for 2D stuff. So far, it went very smooth. I just use the original documentation. https://github.com/SiegeLord/DAllegro5 Who else uses DAllegro 5? I like it, just can't get it to work on OS X. I'm also using the Allegro bindings for a project and have run into no issues on Linux. I'm using Dgame on another project on and that also works very well. @SiegeLord: It would be good to get those bindings listed on the main Allegro site here: http://alleg.sourceforge.net/bindings.html (there is an old listing for Allegro 4 but not 5) and in their news here if possible: http://alleg.sourceforge.net/news.html I believe you just need to send a request to the mailing list here: http://sourceforge.net/p/alleg/mailman/?source=navbar Cheers uri
Re: D3
On Tuesday, 9 December 2014 at 10:49:13 UTC, Chris wrote: On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Well, the name of D is "D" not "D(n)", so there should be no problem in case they want to sue Walter. But really, it had to be JavaScript of all languages! At least it's not PHP. I prefer PHP, at least it's an explicit hack on sight.
Re: Need help deciphering posix.mak
On Friday, 5 December 2014 at 10:48:15 UTC, Daniel Murphy wrote: "Dicebot" wrote in message news:kgogertqxpmczhoqr...@forum.dlang.org... That or just clean up the existing makefiles (getting rid of DMC make and using GNU make on all platforms would be ideal). Or just doing nothing - while existing build system is quite a mess, the problem is not critical enough to extend the infrastructure. As much as I dislike digital mars make, requiring GNU make on windows would be worse. One of these days I'm going to rewrite the dmd test suite to not require make at all, but I'm going to have to figure out how it works first. I think I'd much rather GNU make. No offence, but there's no chance your little tool will ever get the same test coverage or real-world use testing of GNU make on Windows. This is why I prefer CMake like tools over dub. Plus make -jX is *much* faster than dub build (and SCons for that matter). /uri
Re: Why is `scope` planned for deprecation?
On Wednesday, 19 November 2014 at 01:35:19 UTC, Alo Miehsof Datsørg wrote: On Tuesday, 18 November 2014 at 23:48:27 UTC, Walter Bright wrote: On 11/18/2014 1:23 PM, "Ola Fosheim Grøstad" " wrote: I am arguing against the position that it was a design mistake to keep the semantic model simple and with few presumptions. On the contrary, it was the design goal. Another goal for a language like C is ease of implementation so that you can easily port it to new hardware. The proposals I made do not change that in any way, and if K&R designed C without those mistakes, it would have not made C more complex in the slightest. VLAs have been available in gcc for a long time. They are not useless, I've used them from time to time. I know you're simply being argumentative when you defend VLAs, a complex and useless feature, and denigrate simple ptr/length pairs as complicated. Argumentative ?!! More like a fucking gaping fucking asshole. His posts are the blight of this group. Wow that's uncalled for. I don't always agree with Ola but his posts are rarely uninformed and often backed up with actual code examples or links supoprting his arguments. They generally lead to very interesting discussions on the forum. Cheers, uri
Re: 'int' is enough for 'length' to migrate code from x86 to x64
On Wednesday, 19 November 2014 at 18:09:11 UTC, Ary Borenszweig
wrote:
On 11/19/14, 7:03 AM, Don wrote:
On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise
wrote:
>
Weird consequence: using subtraction with an unsigned type is
nearly
always a bug.
I wish D hadn't called unsigned integers 'uint'. They should
have been
called '__uint' or something. They should look ugly. You need
a very,
very good reason to use an unsigned type.
We have a builtin type that is deadly but seductive.
I agree. An array's length makes sense as an unsigned ("an
array can't have a negative length, right?") but it leads to
the bugs you say. For example:
~~~
import std.stdio;
void main() {
auto a = [1, 2, 3];
auto b = [1, 2, 3, 4];
if (a.length - b.length > 0) {
writeln("Can you spot the bug that easily?");
}
}
~~~
Yes, it makes sense, but at the same time it leads to super
unintuitive math operations being involved.
Rust made the same mistake and now a couple of times I've seen
bugs like these being reported. Never seen them in Java or .Net
though. I wonder why...
IMO array length should be unsigned but I'd like to see unsafe
operators on unsigned types illegal. It is trivial to write
(a.signed - b.signed) and it should be explicit in the code, i.e.
not something that the compiler will do automatically behind the
scenes.
Cheers,
uri
Re: Friendly C link
These are of similar nature I believe for c++ http://www.csse.monash.edu.au/~damian/papers/PDF/ModestProposal.pdf http://www.csse.monash.edu.au/~damian/papers/PDF/SPECS.pdf This paper was by my c++ lecturer at the time it was published. A fantastic coder as well as academic who unfortunately was lost to Perl around the same time :D Below is an example of what that does to a person :) http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html Cheers uri
Re: SWIG?
On Thursday, 28 August 2014 at 01:08:43 UTC, Scott Wilson wrote:
SWIG has D support. But it seems old and out of fashion.
Community here does not buzz about it much either. Whats the
word on the street about the quality of SWIG-D stuff?
Scott
PS thankyou Walter for replying
The swig bindings are good and I use them quite a bit to
interface with legacy C++ projects.
This might be fixed already, I don't know and haven't tracked it
but I had to make a minor change to the binding generator, as
shown below.
edit commoncore_im.d and change the following:
---
mixin template SwigOperatorDefinitions() {
...
static if (is(typeof(swigOpEquals(rhs {
return swigOpEquals(rhs);
} else {
...
---
to
---
mixin template SwigOperatorDefinitions() {
...
static if (is(typeof(swigOpEquals(rhs {
return cast(bool)(swigOpEquals(rhs)); // <-- cast(bool)
added
} else {
...
---
cheers, uri
Re: Voting: std.logger
On Wednesday, 30 July 2014 at 00:15:26 UTC, H. S. Teoh via Digitalmars-d wrote: On Tue, Jul 29, 2014 at 04:55:04PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 7/29/14, 4:16 PM, H. S. Teoh via Digitalmars-d wrote: >On Tue, Jul 29, 2014 at 11:09:27PM +, Robert burner >Schadek via Digitalmars-d wrote: >>On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei >>Alexandrescu wrote: >[...] >>>4. Replace defaultLogger with theLog. "Logger" is a word, >>>but one >>>that means "lumberjack" so it doesn't have the appropriate >>>semantics. The use is generally acceptable as a nice play >>>on words >>>and as a disambiguator between the verb "to log" and the >>>noun >>>"log". When we actually want to talk about the current log >>>in an >>>application, we should, however, call it "the log". This is >>>negotiable. >> >>I really don't care how a global Logger instance is called. >>Anyone >>else has an opinion on this? Otherwise Andrei wins. >[...] > >I propose 'stdlog'. I thought of the same but then rejected it - stdlog looks like offering the same interface as stdout and stderr. Nevertheless it's a sensible choice, too. -- Andrei I don't like 'theLog'. What about 'defaultLog'? T +1 for !theLog. I actually like "dlog" because I hate typing but defaultLog would be fine. /uri
Re: Case for std.experimental
On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote: [snip] I wonder what are other opinions. Here's what I'd like to see as a D user with std.experimental... dub: ==> free-for-all libraries of varying quality ==> Promoted on official D website. ==> Included in the D download std.experimental: ==> Released with Phobos ==> Reviewed modules by core D devs, akin to BETA/RC ==> Guarantees on API stability but not set in stone. ==> [maybe?] Changes require deprecation and another round in std.experimental std: ==> High quality with API in stone. ==> Modules have been through 2 rounds of review ==> Changes require deprecation over a longer period. Cheers, uri.
Re: [OT] Re: Redesign of dlang.org
On Monday, 28 July 2014 at 09:16:44 UTC, Gary Willoughby wrote: You said you don't like it and you were heard the first time I'm speaking the truth which often hurts. Yes and I don't see w0rp running off and sulking about it either. Your problem is you are not able to take any criticism whatsoever against this piece of work. The design is awful, period. I have nothing against you personally and i think it's good that you are initiating this effort but the design is the first thing that should be addressed and in no way be an afterthought. I apologise if i sound terse but usually in my line of work shoddy efforts have to be address upfront and with prejudice. w0rp et. al. have asked for your contributions in art/design because you say you know how to do a better job. The very first thing you should of done is to create mockups (in photoshop, etc) of what each page should look like and make sure the design can accommodate all the content. Once the design is approved then implement the site. The backend is inconsequential, use whatever you are comfortable with. Vibe.d, LAMP it doesn't matter. Users don't care about the backend. What matters is the user experience (especially within the documentation) and that is what should be addressed in a thoughtful professional matter. This is not optional or something that should be done along the way. Stating something is crap in a volunteer project is useless unless you can follow it up with something equally useful. For an engineer you sound just like our marketing team at work: Always ready to produce some warm and fuzzy ideas but light on the specifics and actual work. /uri
Re: Random points from a D n00b CTO
On Monday, 14 July 2014 at 06:13:38 UTC, Manu via Digitalmars-d wrote: On 14 July 2014 14:47, uri via Digitalmars-d wrote: On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote: - I was *very* disappointed that using base library locks you into GC vs ref. counting. Separate, I like how Objective C has NSObject for GC purpose(I'd love a framework that is just ref counting), but there should be dual libs and base should not be GC. This topic was bashed to death. There were compelling arguments from both sides, but in the end no one pushing for ARC could produce evidence that it was better than GC. Andrei himself pushed such evidence in an interesting case study that explored a high-end ARC implementation. It compared impressively with 'the fastest GC's' (or some description very close to that). D's GC is certainly not among those in comparison, which suggested the paper's tech would probably be a win for D no matter how you look at it. And the counter evidence is overwhelming. As many times as I've asked the experts for comment, I've still *NEVER* heard anybody disagree that D's GC will probably remain really bad for the indefinite future. Even the ones that are strongly in favour of GC; nobody seems to know how to do it, and many have said it's probably impossible. Even if it was theoretically possible, that only solves one of numerous problems... Nobody has ever addressed the low-available-memory argument I've put forward a number of times, which is the standard operating environment of most embedded computers. So, I don't feel like there was any such conclusion as you suggest. Personally, I just became horribly apathetic and gave up. My general participation and motivation in this community has declined significantly as a result. I'm among the minority that REALLY care about this, and it's clear (and it's been made clear) that if I'm not prepared to work on it myself, then it won't move forward. That's fine, and it's perfectly reasonable. But I'm not in the least bit interested in working on GC technology myself - I'm not an expert, and it's not a field that interests me, thus I decided to desist participating in discussions. Currently there's a big push to remove hidden GC allocs from Phobos, starting with @nogc. std.allocators is just around the corner as well, which will provide a solid framework to build better allocation strategies. We're yet to see how to use the allocators API to specify a replacement default allocator used by the languages intrinsic allocations, which makes it rather less exciting. Anyone can invent an allocator interface, but designing it such that it can be used to configure the languages implicit allocations is much more complex. I'm concerned that Andrei's allocator interface doesn't actually address this... At least, I haven't seen any discussion about how it will. That said, I'm not trying to down-play the importance of a standard allocator API, and Andrei's development is very important and appreciated, but I am yet to find out how it actually addresses any of my real concerns relating to allocation. As I see it, I have zero concern about allocations I control. I am entirely concerned with intrinsic/implicit allocations that I don't, and may potentially (likely) originate from within 3rd party libraries. All good points. Thanks and my bad for the misinformation, sorry. uri
Re: Random points from a D n00b CTO
On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote: Hi all, I'm a CTO at a start up and interested in porting our Java project to D. Some points, I have been lurking on D for years, went to my first D conf recently. Also I was one of top 20 people to join Java Struts, and that grew to 3million plus end users so I have some 'cred'. Hope this helps: - Confusing forum. First listed forum on 'D' is not for D users, but it's called D! It is in fact for D commiters. This causes frustration for both users and commiters. (yes there is 'learn D' but it's 4th down. Commiters forum should be slightly hidden and user questions should not be answered in commuters but politely asked to post in the proper forum.). I agree. It doesn't bother me personally, but I think the discussions about lang design etc. should be under "D Programming Language - Development". A new user might be put off by all the heated discussion about the language design and get the impression D is still in flux. - I was *very* disappointed that using base library locks you into GC vs ref. counting. Separate, I like how Objective C has NSObject for GC purpose(I'd love a framework that is just ref counting), but there should be dual libs and base should not be GC. This topic was bashed to death. There were compelling arguments from both sides, but in the end no one pushing for ARC could produce evidence that it was better than GC. Currently there's a big push to remove hidden GC allocs from Phobos, starting with @nogc. std.allocators is just around the corner as well, which will provide a solid framework to build better allocation strategies. - D is/has become complex. metaprograming, generics, macros, etc. This is a culture issue, very hard to fix cultural issues w/o losing most commiters. Just a fast system lang w/o headers, 'boost' and such. All this other stuff can be 3rd party eco system and should be pushed out from D proper into implementations and add ons. This is why I use D. After many years in C++ I am not fond of templates but in D they are almost transparent and so simple to use. They provide amazing code reuse and CTFE for almost zero additional complexity over run-time code. - Dub rocks. That is does, although I still use CMake :) - Very little 'user' outreach. Meetups such as 'learn D' (set up editor w/ DUB, and write some vibe.d DNS client/server in 4 lessons). Or how to use a c .so lib. So hth. FYI I plan to hire 3+ 'D lang' programmers (users, not commuters) to rewrite the Java project in Dallas and/or San Jose (CA) over the next few months (Feel free to ping me @puppetMaster3, ideal candidate is 'prolific' and career programmer) Cheers, Vic Good luck! Thankfully I can use D at work now, if I couldn't you would have my CV within the hour :-) Cheers, uri
Will std.experimental be shipped with DMD zip package?
I assume it will but thought I'd ask all the same... I only use the latest official release and would still like to bash on std.experimental modules so I hope it will be in 2.066.zip. Thanks, uri
