Getting started with D - Phobos documentation sucks
Hi guys. I was browsing the book "Programming in D" by Ali Çehreli. It was pretty much clear, and then I stumbled upon this on page 89: 20.9 Exercises 1. Browse the documentations of the std.string, std.array, std.algorithm, and std.range modules. OK, let's open the D website and browse the documentation of std.string: http://dlang.org/phobos/std_string.html What do we see? A bunch of links that look like SEO tags of a spam website, followed by a mess of anything - structs, classes, functions, and what not. Do you really think somebody who learns programming can understand anything here? Compare this with, e.g., an msdn reference: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684852(v=vs.85).aspx A clear division of enums, functions, macros, structs, ... http://msdn.microsoft.com/en-us/library/windows/desktop/ms684847(v=vs.85).aspx The functions are divided by usage, with a short explanation next to each function. I think documentation is really important, and something has to be done about it. How can a newcomer get started with D when he doesn't have a readable documentation of Phobos?
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 15:46:36 UTC, MattCoder wrote: On Saturday, 29 September 2012 at 15:29:46 UTC, Mr. Anonymous wrote: 1. Browse the documentations of the std.string, std.array, std.algorithm, and std.range modules. OK, let's open the D website and browse the documentation of std.string: http://dlang.org/phobos/std_string.html What do we see? A bunch of links that look like SEO tags of a spam website, followed by a mess of anything - structs, classes, functions, and what not. Compare this with, e.g., an msdn reference. Just remembering that most of the things that you see here is made by the community itself and the most important, it's free. But well this is not an excuse, but anyway, Microsoft come doing this since long time ago and was not always as you see today. Don't get me wrong, I'm not saying somebody owes me something. I love D and appreciate the effort the community puts in it, otherwise I probably wouldn't write this post. I'm just saying that, in my opinion, it's a high priority and it has to be addressed, so that newcomers would be able to get started with D.
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 15:29:46 UTC, Mr. Anonymous wrote: Hi guys. I was browsing the book "Programming in D" by Ali Çehreli. It was pretty much clear, and then I stumbled upon this on page 89: 20.9 Exercises 1. Browse the documentations of the std.string, std.array, std.algorithm, and std.range modules. OK, let's open the D website and browse the documentation of std.string: http://dlang.org/phobos/std_string.html What do we see? A bunch of links that look like SEO tags of a spam website, followed by a mess of anything - structs, classes, functions, and what not. Do you really think somebody who learns programming can understand anything here? Compare this with, e.g., an msdn reference: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684852(v=vs.85).aspx A clear division of enums, functions, macros, structs, ... http://msdn.microsoft.com/en-us/library/windows/desktop/ms684847(v=vs.85).aspx The functions are divided by usage, with a short explanation next to each function. I think documentation is really important, and something has to be done about it. How can a newcomer get started with D when he doesn't have a readable documentation of Phobos? OK, I looked at it, and I saw that the links are generated by javascript. So I decided to try and write a better javascript function for creating links. Here's what I came up with: The JS code: http://pastebin.com/Pz4fb4JR Screenshots: http://i.imgur.com/gwxrI.png, http://i.imgur.com/qGGQn.png As you can see, the code works for both the website html and the one bundled with dmd. If my function finds nothing, it falls back to it's old version of anchor list. This solution is quite bad and temporary, but what we have now is not much better, so, for a while, I think it's worth using. P.S. I saw in the comments that Adam D. Ruppe came up with a better solution, but it requires an external tool. My solution requires a small javascript change, which should be very easy to integrate.
Re: Getting started with D - Phobos documentation sucks
On Monday, 1 October 2012 at 19:39:35 UTC, Piotr Szturmaj wrote: Mr. Anonymous wrote: OK, I looked at it, and I saw that the links are generated by javascript. So I decided to try and write a better javascript function for creating links. Here's what I came up with: The JS code: http://pastebin.com/Pz4fb4JR Screenshots: http://i.imgur.com/gwxrI.png, http://i.imgur.com/qGGQn.png As you can see, the code works for both the website html and the one bundled with dmd. If my function finds nothing, it falls back to it's old version of anchor list. This solution is quite bad and temporary, but what we have now is not much better, so, for a while, I think it's worth using. I've also tried to improve it: http://forum.dlang.org/thread/jb0ril$17oa$1...@digitalmars.com But I think that top positioned index is bad. It should be on the left, or the right pane. Why hasn't it been integrated? I guess the reason is that everybody says "that's not a solution, we have to fix x and y", but nobody actually fixes that stuff, and the reality is that we're left with an unusable list of anchored SEO-spam links for years. That's why I did the change as simple as possible - it should take no more than a minute to replace the function. P.S. can somebody create a pull request for this at github? I'm not familiar with this stuff.
Re: dlang.org Library Reference
On Monday, 10 December 2012 at 02:10:43 UTC, Ellery Newcomer wrote: Is anyone else noticing e.g. std.datetime taking upwards of 30 seconds to render the blob of links at the top? It's freakin freezing my entire browser. ddox* on dlang.org, anyone? http://vibed.org/temp/phobos/index.html * https://github.com/rejectedsoftware/ddox
Re: BigInt bool assign
On 23.12.2011 14:42, bearophile wrote: D language regards boolean values as a subset of integers so it allows implicit conversion from bool to integer, but not from int to bool. I don't think this will ever change in D2/D3: Discussing about pros and cons of such implicit conversion is one thing, but that's already how it works for basic types, so I agree it must work for more advanced ones. After all, BigInt is a big int, and it should feel like that. If one expects a += (b < c); to work for an int (and it works), it should work for BigInts as well. Another option is also disabling it for basic types, but better not define different behavior for similar types.
Re: BigInt bool assign
On 24.12.2011 12:33, Don wrote:
On 24.12.2011 02:30, Derek wrote:
On Sat, 24 Dec 2011 09:19:26 +1100, bearophile
wrote:
This is why it's better to avoid casts, not requiring them in the
first place, unless they are useful. In this case I think a cast
introduces more danger than the risks caused by implicit bool->int
conversions.
If we assume that explicit casts are required for bool->int conversion,
can you show some code in which this could cause a problem?
I think stuff like
int z += x > y;
should ideally require a cast. That's a crazy operation.
The problem is compatibility with ancient C code (pre-C99), where you
may find:
alias int BOOL;
BOOL b = x > y;
Although BOOL is typed as 'int', it really has the semantics of 'bool'.
We have an example of this in D1's opEquals().
I think this is reason why implicit conversion bool -> int exists.
BTW, great to see you again, Derek!
The D Programming Language, page 172:
for (; n >= iter * iter; iter += 2 - (iter == 2)) { ...
:)
Re: State of the forum
Also the user habit due to the combined use of the forum as an email discussion and as a website forum of repeating the whole of a post, often to respond with a one-liner. Posts without the whole email/context repeated receive complaints that people do not know what it is in response to. I'll implement some warnings when a user attempts to post a message not conforming to netiquette. A suggestion: Can you make the quotes hidden by default, like e.g. in Gmail or Google Groups? That would be perfect. (http://i.imgur.com/axuAFvz.png)
Re: Was: Re: Vote for std.process
void oldWay(string[string] environment)
{
auto envz = new const(char)*[environment.length + 1];
int pos = 0;
foreach (var, val; environment)
envz[pos++] = (var~'='~val~'\0').ptr;
exec(envz);
}
void newWay(string[string] environment)
{
auto buf = staticAppender!(4096, char)();
StaticArray!(64, size_t) envpBuf;
size_t[] envp = envpBuf.get(environment.length + 1);
size_t pos;
foreach (var, val; environment)
{
envp[pos++] = buf.data.length;
buf.put(var);
buf.put('=');
buf.put(val);
buf.put('\0');
}
// Convert offsets to pointers in-place
auto envz = cast(const(char)*[])envp;
foreach (n; 0..pos)
envz[n] += cast(size_t)buf.data.ptr;
exec(envz);
}
I just thought of something!
I don't comment here often, but I want to express my opinion:
Currently D, being a system language, offers full control over
the allocation method, be it the stack or the heap. The helpers
above show how flexible it is in doing custom optimized stuff if
one wants to. But there's an obvious drawback, quoting Vladimir:
"the code is quite more verbose, even with the helper types. It's
no longer obvious at a glance what the code is doing."
But think for a moment - does the programmer usually needs to
choose the allocation method? Why explicit is default?
It could be the other way around:
void oldWay(string[string] environment)
{
const(char)* envz[environment.length + 1]; // Compiler
decides whether to use stack or heap.
int pos = 0;
foreach (var, val; environment)
envz[pos++] = (var~'='~val~'\0').ptr; // Use appender.
Use stack and switch to heap if necessary
exec(envz);
}
How nifty would that be, don't you think?
Another benefit could be that the compiler could adjust the stack
allocation limit per architecture, and probably it could be
defined as a command line parameter, e.g. when targeting a low
end device.
This principle could work on fields other than allocation, e.g.
parameter passing by ref/value. The programmer needs to only
specify whether he wants a copy or the actual value, and the
compiler would decide the optimal way to pass it.
e.g.:
immutable int n;
func(n); // by value
immutable int arr[30];
func(arr); // by ref
But these are probably suggestions for D3 or something... Too
drastic :)
Re: Was: Re: Vote for std.process
After some Googling, I found out a similar technique already exists: auto_buffer in C++. http://goo.gl/3RLK6 I think it would be perfect to make it the default allocation method in D.
Re: Twitter widget cut on dconf.org on Chrome/OSX
On Monday, 22 April 2013 at 15:57:28 UTC, Andrei Alexandrescu wrote: We have a bit of trouble with the Twitter widget on Chrome, at http://dconf.org/talks/lucarella.html. The widget is chopped at the bottom. Is there a simple fix for this? Thanks, Andrei A more serious issue is that the speakers page is chopped in Firefox: http://dconf.org/speakers/index.html It lists only until Dmitry Olshansky. No wonder, as it has a fixed size in pixels.
Re: Twitter widget cut on dconf.org on Chrome/OSX
On Monday, 22 April 2013 at 17:11:49 UTC, Steven Schveighoffer wrote: On Mon, 22 Apr 2013 12:50:50 -0400, Mr. Anonymous wrote: A more serious issue is that the speakers page is chopped in Firefox: http://dconf.org/speakers/index.html It lists only until Dmitry Olshansky. No wonder, as it has a fixed size in pixels. I don't see that problem in firefox, or opera -Steve I did a refresh, and it works now. Cache, I guess. Sorry for the false alert.
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 16:07:59 UTC, Andre Artus wrote: I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. I would like for there to be a section were people interested in working on the docs can collaborate. Related: http://forum.dlang.org/post/bxqyiyohbodlxypxg...@forum.dlang.org
Re: Can we get a forum section devoted to documentation? [dox]
On Friday, 16 August 2013 at 18:12:57 UTC, Andre Artus wrote: Is there a way to break the pages into a more of a hierarchy, so that documentation for each module doesn't have to be on one page? Perhaps a DDOC Section could indicate the category? Are you familiar with DDOX? http://vibed.org/temp/d-programming-language.org/phobos/index.html
Re: Can we get a forum section devoted to documentation? [dox]
On Friday, 16 August 2013 at 19:27:58 UTC, Andre Artus wrote: On Friday, 16 August 2013 at 19:12:46 UTC, Mr. Anonymous wrote: On Friday, 16 August 2013 at 18:12:57 UTC, Andre Artus wrote: Is there a way to break the pages into a more of a hierarchy, so that documentation for each module doesn't have to be on one page? Perhaps a DDOC Section could indicate the category? Are you familiar with DDOX? http://vibed.org/temp/d-programming-language.org/phobos/index.html I have not yet had the time to look into it, but I fear that it would be of little use if it's not the official way of doing docs. Although it may be the preferred option for private projects or projects not directly connected to the main D ecosystem. There is already quite a lot of fragmentation making it quite an effort to find out what the "one true path"[1] is. 1. I realize that there isn't truly such a thing, but an opinionated starting point is of great help to noobs. The major feature to popularize Ruby on Rails when it first kicked off was, in my opinion, the "on rails" part. You had a very clear indication of where to start, and what the best/accepted/expected practices are. Once you have accustomed yourself to the language and framework you can find ways to go crashing through the bushes if you feel the need to do so. It's planned as the official way of doing docs. There are pull request for it, but it's going nowhere for the past several months. A related thread: http://forum.dlang.org/thread/dsnpggjmndaxiusfq...@forum.dlang.org
Re: A Discussion of Tuple Syntax
On Monday, 19 August 2013 at 18:43:37 UTC, Meta wrote:
On Monday, 19 August 2013 at 16:53:06 UTC, Wyatt wrote:
Can't make it a single underscore? Question mark works best
then, IMO. It isn't as burdened with meanings elsewhere (sure
there's ternary and possibly-match in regex, but...have I
forgotten something?)
It *could* be an underscore; the only thing is that the
underscore is a valid variable name, so the above expression
would actually be binding two variables, which might surprise
someone who was expecting otherwise. I don't really care all
that much, but it's something to think about.
Why not just leave an empty space, like php does:
$info = array('coffee', 'brown', 'caffeine');
// let's skip to only the third one
list( , , $power) = $info;
echo "I need $power!\n";
http://php.net/manual/en/function.list.php
Re: A Discussion of Tuple Syntax
On Tuesday, 20 August 2013 at 10:38:30 UTC, eles wrote:
On Friday, 16 August 2013 at 21:07:52 UTC, Meta wrote:
A good, comprehensive design has the potential to make tuples
easy to use and understand, and hopefully clear up the
unpleasant situation we have currently. A summary of what has
been discussed so far:
- (a, b) is the prettiest syntax, and it also completely
infeasible
- {a, b} is not as pretty, but it's not that bad of an
alternative (though it may still have issues as well)
- #(a, b) is unambiguous and would probably be the easiest
option. I don't think it looks too bad, but some people might
find it ugly and noisy
What about:
!!(a, b)
? Yes, is long, but is type-able quite fast.
Alternative would be:
??(a, b)
.
It's not only long, but also ugly (IMO of course).
Re: Allocators
On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote: On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote: On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic wrote: On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote: I see Andrei running away ! I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P Or auto ref. ;) Or shared. Or const. Or scope. Or Object methods. There's quite a few unresolved issues! How about adding those to the TODO list? e.g. http://dlang.org/todo.html Or make a wiki page?
Adding D books to the list of freely available programming books
On Stack Overflow: http://stackoverflow.com/questions/194812/list-of-freely-available-programming-books I don't have a user with edit privileges, but it would be nice to add the D books: Programming in D ddili.org/ders/d.en/ D Template Tutorial raw.github.com/PhilippeSigaud/D-templates-tutorial/master/D-templates-tutorial.pdf There's also http://progmofo.com/, but I didn't find a contact link.
Re: Stable D version?
On Monday, 29 April 2013 at 08:07:05 UTC, eles wrote: I even start thinking that is better to release a new feature after a relative short, preliminary discussion, and be prepared to change it during a time frame, if it is not as practical as desired, instead of prolonging a discussion for centuries in the search of the perfect implementation. That brings us back to the "Stable D" subject, and the separation between stable and unstable. Those preliminary features should be included in the unstable releases, where changes can be made without the fear of breaking things. Then, after some actual usage, they would be merged to the stable branch.
Re: New documentation
On Thursday, 9 May 2013 at 22:02:55 UTC, John Colvin wrote: Unless I've missed something, it's been a while since this was talked about: http://vibed.org/temp/phobos/std/array.html I personally think this would be a great replacement (with a few things fixed, like the broken html links). What's stopping the ball rolling on this? I suggest that it is added to dlang.org as an optional "alternate view" for the documentation. This would allow some real-world testing and wider review. There's also this: http://vibed.org/temp/d-programming-language.org/phobos/index.html
Re: Issue 3789 and some interesting pull requests
On Wednesday, 8 May 2013 at 03:03:16 UTC, bearophile wrote: Maybe Kenji and others have fixed one important bug: http://d.puremagic.com/issues/show_bug.cgi?id=3789 - - - - - - - - - - - On GitHub there are many open pull requests for dmd, and some of them look quite interesting (even if some of them probably need to be improved): This allows to support a[$-1, 2..$], it's useful to implement a good vector library in D: https://github.com/D-Programming-Language/dmd/pull/443 To improve the type merging in array literals: https://github.com/D-Programming-Language/dmd/pull/684 __ctfeWrite and __ctfeWriteln, I'm asking for a better compile time printing since years: https://github.com/D-Programming-Language/dmd/pull/692 Taking the address of a deprecated function should trigger a deprecated message, etc: https://github.com/D-Programming-Language/dmd/pull/1064 This is for a small but handy change in D that allows to write "new C().foo();" instead of "(new C()).foo();". https://github.com/D-Programming-Language/dmd/pull/ Support for T() syntax for build-in types. This avoids to use an ugly cast() in some cases: https://github.com/D-Programming-Language/dmd/pull/1356 Overloading template and non-template functions: https://github.com/D-Programming-Language/dmd/pull/1409 With value range propagation we can disable some array bound tests: https://github.com/D-Programming-Language/dmd/pull/1493 To improve the use of template functions in different modules: https://github.com/D-Programming-Language/dmd/pull/1660 Recursive build for the compiler: https://github.com/D-Programming-Language/dmd/pull/1861 To make D more flexible, allowing the idea of a library-defined dup: https://github.com/D-Programming-Language/dmd/pull/1943 Bye, bearophile Isn't it better to merge these before DDMD?
Re: primitive value overflow
On Thursday, 16 May 2013 at 20:29:13 UTC, Andrej Mitrovic wrote: On Thursday, 16 May 2013 at 20:24:31 UTC, luka8088 wrote: Hello everyone. Today I ran into a interesting issue. I wrote auto offset = text1.length - text2.length; Yeah, I don't like these bugs either. In the meantime you can swap auto with 'sizediff_t' or 'ptrdiff_t', and then you can check if it's non-negative. It's exactly the same as checking if(text1.length > text2.length). But the idea of checking for integer overflows in debug builds is really nice. P.S. I remember Microsoft had some serious bug because of an integer overflow, that allowed a remote machine to create a denial of service.
Re: primitive value overflow
On Thursday, 16 May 2013 at 21:04:38 UTC, Jonathan M Davis wrote: On Thursday, May 16, 2013 22:42:23 luka8088 wrote: I agree that it is exactly the same as checking if (text1.length > text2.length). And I don't think that this is an issues if you are aware of the fact that you are working with unsigned values. But in the code that I wrote there was no mentioning of unsigned so the possibility of that kind of issue never came to mind until I actually printed the values. And that is what I wanted to emphasize. Well, I'm not sure what can be done about that. length is size_t, which is the unsigned integral value which matches the architecture (uint for 32-bit and ulong for 64-bit). AFAIK, the documentation is clear on this (though I haven't read it recently). If it's not, then it should be made clearer, but using size_t for length is pervasive in D as it is in C++, and if you know the standard types, you know what size_t is. As for overflow checking, it's come up quite a few times, and Walter is completely against it. The hardware doesn't support it, and it would definitely be slow if it were added. The standard way to handle that if you want it is to create user-defined integral type which does the checks (though that obviously won't help you when you can't control the types that you're dealing with). But if you want to add checks in your code, you can always create a wrapper function for doing the subtraction. And if you wanted the checks to only be there in non-release mode, then you could even put the checks in a version(assert) block. So, you can add checks if you want them, but there's pretty much no way that how unsigned or overlflow are handled in the language is going to change. - Jonathan M Davis I agree with Walter if we're talking about production code, but I think it could be very helpful for debug builds. P.S. The hardware doesn't support it That's not completely true. e.g. x86, while it doesn't throw an exception on an overflow, it does set a flag, which could be relatively cheaply checked.
Re: rename our github organization?
On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote: I'm thinking we should rename D-programming-language on github with dlang. While we're at it, project d-programming-language.org should be renamed dlang.org. This may cause disruption. Thoughts? Andrei The URL in the description of dmd, druntime, tools, installer is also outdated.
DSoC + Kickstarter?
As you probably know, the application of D to GSoC 2013 has been rejected. There was an idea about running the program nonetheless, minus the funding: http://forum.dlang.org/post/mailman.613.1365489754.4724.digitalmars-d-annou...@puremagic.com Can't we use Kickstarter to fund it?
Re: Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)
On Sunday, 19 May 2013 at 20:03:24 UTC, Andrei Alexandrescu wrote: Well you got to do what you got to do. Field accesses for objects larger than 4KB would have to be checked in @safe code. Isn't the solution as easy as doing: OR PTR:[address], 0 the same way it's done for the stack? The offset it known at compile time in most cases, so the command would be required only if both: * The object is larger than target OS' guard page size. * The position is greater than target OS' guard page size, OR is unknown at compile time.
Re: DSoC + Kickstarter?
On Saturday, 18 May 2013 at 08:33:10 UTC, Mr. Anonymous wrote: As you probably know, the application of D to GSoC 2013 has been rejected. There was an idea about running the program nonetheless, minus the funding: http://forum.dlang.org/post/mailman.613.1365489754.4724.digitalmars-d-annou...@puremagic.com Can't we use Kickstarter to fund it? Seems like KolibriOS did exactly this: http://www.kickstarter.com/projects/kolibrios/kolibrios-help-us-hold-our-own-summer-of-code-2013 It's probably too late for D now, though.
Re: Ideal D GUI Toolkit
On Monday, 20 May 2013 at 05:25:50 UTC, Tyler Jameson Little wrote: I've been looking into trying to fix QtD, but it seems writing a binding to a C++ library is a bit complicated. I've read on the forums that a native D GUI toolkit is the most desirable long-term, so I'd like to start that discussion. First off, I've heard of the DWT project, which looks promising, but it seems like a direct port of Java's SWT instead of a reimagining using idiomatic D. I understand the allure here (works, little translation for new developers), but since it's not yet in Phobos, I can only assume it's still up for discussion. Personally, I want these features: * simple and extensible * minimal components (something like HTMLs feature-set) * custom components (embed OpenGL/direct frame buffer) * "native" window decorations by default, but can provide custom decorations * markup (like QML) or programmable (like SWT) Nice-to-haves: * hardware accelerated (2D OpenGL) * GUI designer (much easier with QML-esque markup) * part of Phobos I'm willing to lend a hand, but I'd like to know in what direction the community would like to go. I'd also like to know the likelihood of getting a GUI toolkit into Phobos. Thoughts? What about D Forms Library (DFL)? I didn't try it yet, but I've heard it's not bad. https://github.com/Rayerd/dfl
Re: new DIP41: dmd/rdmd command line overhaul.
On Tuesday, 21 May 2013 at 09:45:19 UTC, Timothee Cour wrote: Abstract: This DIP seeks to improve dmd and rdmd's command line flags, to make it more self-consistent and consistent with other tools (including other D compilers), more expandable, avoid existing corner cases, and better interact with other tools such as rdmd. It also proposes new flags and proposes a simple deprecation path to follow. Link: http://wiki.dlang.org/DIP41 Too many DIPs, none of which is actually implemented. Looks like your strategy is flawed.
Re: new DIP41: dmd/rdmd command line overhaul.
On Thursday, 23 May 2013 at 09:29:22 UTC, Dicebot wrote: On Thursday, 23 May 2013 at 09:26:31 UTC, Walter Bright wrote: On 5/23/2013 2:01 AM, Dicebot wrote: See current beta mailing list for several examples of what should have never happened in real stable development process. The reason it is a beta is so we can identify problems and deal with them before a release. In perfect world beta exists to identify problems _unknown_ before. Almost all issues I have seen mentioned so far was known by developers (those were bug fixes after all) but considered acceptable to put into compiler anyway. And that is a problem. I don't think it's possible for a language to both evolve and keep being stable. At least not with the current release process, with a single branch. There should at least be 2 branches - stable (as in binary stable - 0% code breakage), and experimental/beta/you name it, which breaks code when reasonable. Then, after some amount of time, this experimental branch becomes the new stable branch (while the previous is still available for download). I think the "Development and Release Process" wiki page proposes exactly that. http://wiki.dlang.org/Release_Process
Re: Why UTF-8/16 character encodings?
On Sunday, 26 May 2013 at 19:05:32 UTC, Joakim wrote: On Sunday, 26 May 2013 at 18:29:38 UTC, Andrei Alexandrescu wrote: On 5/26/13 1:45 PM, Joakim wrote: What is extraordinary about "UTF-8 is shit?" It is obviously so. Congratulations, you are literally the only person on the Internet who said so: http://goo.gl/TFhUO Haha, that is funny, :D though "unicode is shit" returns at least 8 results. How many people even know how UTF-8 works? Given how few people use it, I'm not surprised most don't know enough about how it works to criticize it. On the other hand: https://www.google.com/search?q=%22utf-8+is+awesome%22 :D
Re: Why UTF-8/16 character encodings?
On Sunday, 26 May 2013 at 19:25:37 UTC, Joakim wrote: On Sunday, 26 May 2013 at 19:11:42 UTC, Mr. Anonymous wrote: On Sunday, 26 May 2013 at 19:05:32 UTC, Joakim wrote: On Sunday, 26 May 2013 at 18:29:38 UTC, Andrei Alexandrescu wrote: On 5/26/13 1:45 PM, Joakim wrote: What is extraordinary about "UTF-8 is shit?" It is obviously so. Congratulations, you are literally the only person on the Internet who said so: http://goo.gl/TFhUO Haha, that is funny, :D though "unicode is shit" returns at least 8 results. How many people even know how UTF-8 works? Given how few people use it, I'm not surprised most don't know enough about how it works to criticize it. On the other hand: https://www.google.com/search?q=%22utf-8+is+awesome%22 I'm not sure if you were trying to make my point, but you just did. There are only 19 results for that search string. If UTF-8 were such a rousing success and most developers found it easy to understand, you wouldn't expect only 19 results for it and 8 against it. The paucity of results suggests most don't know how it works or perhaps simply annoyed by it, liking the internationalization but disliking the complexity. Man, you're a bullshit machine!
Re: runtime vs compile-time ref safety: 20% overhead in my example
On Sunday, 26 May 2013 at 20:23:45 UTC, Martin Nowak wrote: On 05/26/2013 06:12 AM, Timothee Cour wrote: > Which means that the extra check to make sure the output reference > doesn't escape a local incurs a 20% cost in my example. > > Is there a better implementation (i have a single pointer comparison > though so I'm not sure how that would be optimized) ? > > If not, it will mean user will have to choose between enabling runtime > safety checks (20% in my simple example), or throwing away ref safety by > disabling checkboundsref flag. > If you look at the asm output and lower the iteration count, you'll see that you bench llvm's inliner rather than the cost of the runtime check. Also the version that doesn't perform the bounds check doesn't use the ptr parameter, so the variable can be optimized away. In a real implementation computing the frame pointer doesn't incur much cost, it is already available in a register or it is a constant offset from the stack pointer. The branch is easily predictable, as the condition is always the same. I think the solution proposed in the DIP is worth checking, not solely due to performance reasons, but mainly for better safety. A runtime check cannot check all possible code paths when testing, and an undetected bug can surprise you when you don't expect it.
Re: Skiping whitespace
On Sunday, 26 May 2013 at 22:07:29 UTC, matovitch wrote: up ? I think you'd better repost it on digitalmars.D.learn.
Re: Why UTF-8/16 character encodings?
On Monday, 27 May 2013 at 22:20:16 UTC, H. S. Teoh wrote:
On Tue, May 28, 2013 at 12:04:52AM +0200, Vladimir Panteleev
wrote:
On Monday, 27 May 2013 at 21:24:15 UTC, H. S. Teoh wrote:
>Besides, it's impractical to use compose key sequences to
>write
>large amounts of text in some given language; a method of
>temporarily switching to a different layout is necessary.
I thought the topic was typing the occasional Unicode
character to
use as an operator in D programs?
Well, D *does* support non-English identifiers, y'know... for
example:
void main(string[] args) {
int число = 1;
foreach (и; 0..100)
число += и;
writeln(число);
}
Of course, whether that's a good practice is a different story.
:)
But for operators, you still need enough compose key sequences
to cover
all of the Unicode operators -- and there are a LOT of them --
which I
don't think is currently done anywhere. You'd have to make your
own
compose key maps to do it.
T
http://code.google.com/p/trileri/source/browse/trunk/tr/yazi.d
Re: minifying the website
On Friday, 31 May 2013 at 17:12:11 UTC, Andrei Alexandrescu wrote: Hello, I've been looking through the logs and it looks like the top files in bytes transferred yesterday (even with the deluge of downloads) were a number of Javascript, HTML, and CSS files. There are programs to reduce the size of such files called "minifiers". Should we use some? If so, what would the experts recommend? We'd need ideally some command line utility that we can deploy easily and integrate with the build process. Alternatively, an online service could fit the bill, too. Thanks for your insights, Andrei It would be also great if you could remove that flashing after the page is loaded. I believe it's caused by the bodyLoad() function. Why is it even needed?
Re: The non allocating D subset
On Sunday, 2 June 2013 at 14:32:56 UTC, Adam D. Ruppe wrote: So I tried to get moduleinfo looping working and found some success. If you use it with libc, it works. On bare metal, it works thanks to a linker script hack. It doesn't work on the minimal linux setup. I wasted a lot of hours trying to do it, but there seems to be some elf section magic going on that I can't figure out how to easily hook in to. But even with that working, I couldn't get module ctors working right. Meh time to move on. Here's the list of stuff I'm abandoning so far What doesn't work: 1) array concats. use the module memory.d instead (link failure) 2) module constructors and destructors (silent failure, they never run) 3) looping ModuleInfo without libc or bare metal (silent failure, returns empty list) 4) TLS variables. always use __gshared (runtime crash) 5) threads. 6) unittests (silent failure, they never run) Maybe I can figure out module constructors later, but for now I'm just going to abandon that. How about a wiki page?
Re: Effective D book?
On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:
One issue with local imports is that they hide local symbols.
Can you give an example? I can't repro.
void main()
{
import std.stdio;
void writeln(string) {}
writeln("foo");
std.stdio.writeln("bar");
}
This writes only "bar".
void writeln(string) {}
void main()
{
import std.stdio;
writeln("foo");
std.stdio.writeln("bar");
}
?
Re: Suggesting new changelog format
On Friday, 28 June 2013 at 08:11:04 UTC, Jonas Drewsen wrote: Turn on the sound ;) http://starlogs.net/#D-Programming-Language/dmd /Jonas http://forum.dlang.org/post/xbadgetphtoqaodkl...@forum.dlang.org
Re: Memory management design
On Wednesday, 10 July 2013 at 08:09:46 UTC, Dicebot wrote: Yes, this is a common issue not unique to @nogc. I am personally much in favor of having restrictive attributes enabled by default and then adding "mutable" "@system" and "@allowheap" where those are actually needed. But unfortunately there is no way to add something that backwards-incompatible and attribute inference seems the only practical way (though I hate it). I thought about allowing attributes to be applied to a whole module, such as: @safe @nogc module foo_bar; Then, "@system", "@allowheap" and friends could be used where needed.
Re: Channels for tasks?
On Thursday, 18 July 2013 at 18:38:57 UTC, Matt wrote: On Thursday, 18 July 2013 at 17:55:36 UTC, Sean Kelly wrote: Not as such. I'd like to make Fibers each have their own message queue in std.concurrency, but that means making TLS work at the fiber level, which is tricky. I think there is value in the CSP model (ie. channels), but haven't done anything about it in terms of library work. From what I've read about Fibers, it seems they are more similar to what I'm looking for (a post on stackoverflow implied they are similar to Erlang's implementation of lightweight tasks). Does this mean to say they are similar to the tasks provided by std.parallelism? Thanks for the reply, Matt. vibe.d is based on fibers, you might want to check it out. http://vibed.org/features#fibers
Re: Official D Grammar
On Friday, 19 July 2013 at 20:49:27 UTC, Brian Schott wrote: Status update: My parser is at a point where it can parse all of phobos (well, excluding c-style array declarations, which I'm convinced are broken and should be removed from the language). I've been updating the grammar definition as I worked on the parser. An HTML version is available for download here: https://raw.github.com/Hackerpilot/DGrammar/master/grammar.html Lexer, parser, and AST code is available here: https://github.com/Hackerpilot/Dscanner/tree/range-based-lexer/std/d. Bug reports and pull requests are welcome. https://rawgithub.com/Hackerpilot/DGrammar/master/grammar.html ;)
Re: D roadmap?
On Sunday, 21 July 2013 at 19:43:56 UTC, Rob T wrote: On Sunday, 21 July 2013 at 17:07:56 UTC, Suliman wrote: Do team have any roadmap for D? I mean Language + standard lib. There are the DIP's, which are not exactly a raodmap, but at least can give you a sense of what the outstanding issues are and what the possible solutions may be. http://wiki.dlang.org/Category:DIP --rt http://wiki.dlang.org/DIPs contains some description.
Re: FAQs
On Wednesday, 24 July 2013 at 15:18:20 UTC, Adam D. Ruppe wrote: We should really have an easy to see FAQ on language usage on the homepage and on the D.learn web forum gateway, in the appearance of a sticky thread perhaps. There's a few of the same questions that come up a lot, like I've seen a question about the windows console three or four times in the last six months - pretty often for the same specific question and answer. What I think would be good is to just link to the wiki with a faqs page that can then link elsewhere or write up details and additional resources. There's this: http://dlang.org/faq.html But it seems outdated and broken.
Re: Phobos and older DMD versions
On Tuesday, 6 August 2013 at 14:51:35 UTC, qznc wrote: In my opinion it should, because it makes Phobos development simpler. You don't need a self compiled dmd to fix bugs. On a related note, I think providing compiled daily/weekly master builds is a good idea. They are compiled by the auto tester anyway, right?
Re: Future of string lambda functions/string predicate functions
On Wednesday, 14 August 2013 at 14:36:25 UTC, H. S. Teoh wrote: A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth Heh :) Sometimes I read your replies just for the signature. On the topic, I think the variant with the operators is more straightforward, e.g.: less// a < b op!"<" less!(5)// a < 5 op!"<"(5) etc.
