Re: Three Unlikely Successful Features of D
On Tuesday, 20 March 2012 at 19:02:16 UTC, Andrei Alexandrescu
wrote:
I plan to give a talk at Lang.NEXT
(http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012) with
the subject above. There are a few features of D that turned
out to be successful, in spite of them being seemingly
unimportant or diverging from related consecrated approaches.
What are your faves? I have a few in mind, but wouldn't want to
influence answers.
Thanks,
Andrei
It isn't mainline yet, but UFCS from git has made working with
std.algorithm much nicer. Instead of something like
array(filter!"a > 0"(map!((a){return somefunc(a);})(data))) where
you can quickly drown in parenthesis and the order seems somewhat
backwards, you can use data.map!((a){return
somefunc(a);}).filter!"a > 0".array
Re: Three Unlikely Successful Features of D
On Friday, 23 March 2012 at 04:07:53 UTC, bearophile wrote:
I suggest to compile all your D2 code with -wi (or -w) and
-property.
Already using -w, and I thought I was using -property. I am now,
thanks.
And one bug of UFCS will be probably fixed by Hara
(http://d.puremagic.com/issues/show_bug.cgi?id=7722 ), so map
and filter will require an ending () (I have closed my
http://d.puremagic.com/issues/show_bug.cgi?id=7723 ).
So your last line is better written like this:
data.map!somefunc().filter!q{a > 0}().array()
Yes, I agree. I had to work around a bug a few months ago that
using map!some_nested_func wouldn't compile, and I still haven't
gotten out of the habit of using delegate literals for all but
the simplest maps.
digitalmars-d@puremagic.com
On Tuesday, 27 March 2012 at 15:14:07 UTC, Andrei Alexandrescu wrote: On 3/27/12 6:54 AM, Tyro[17] wrote: On Tuesday, 27 March 2012 at 00:05:51 UTC, Andrei Alexandrescu wrote: On 3/26/12 2:52 PM, Tyro[17] wrote: Couldn't the state of stdin be checked upon entrance into readf and reopened if it is already closed? That won't work. But this does: [snip] Very interesting! But then what if people press Ctrl-C? That would end the input instead of ending the program. Could that technique be used to implement readf for stdin? I don't think we should pursue this path. Wouldn't that accomplish the desired effect while avoiding the pitfalls of scanf? I don't think this is a pitfall. Essentially you don't have a definition of what constitutes a chunk of input. Once you get that define, you should be able to express it more or less easily. I'm of the opinion that Ctrl-D defines the boundary of that chunk of input. We simply have to prevent it from closing the stream when working with stdin. You're in a sparse minority at best. Every Unix application out there uses Ctrl-D for end-of-console-input, and your users would be surprised by your exotic use of it. Why not pick any other character for end of chunk - double newline, Ctrl-S, pretty much anything but Ctrl-D? It's a waste of your time to fight a long-established standard. Andrei GDB handles Ctrl-D differently. It doesn't close the input on the first one, it waits for the second one and then exits. After the first one it acts like you typed 'quit', which asks you if you really want to quit when there's a program still running.
digitalmars-d@puremagic.com
On Tuesday, 27 March 2012 at 19:05:19 UTC, H. S. Teoh wrote: On Tue, Mar 27, 2012 at 08:56:56PM +0200, Matt Peterson wrote: On Tuesday, 27 March 2012 at 15:14:07 UTC, Andrei Alexandrescu wrote: [...] >You're in a sparse minority at best. Every Unix application >out there >uses Ctrl-D for end-of-console-input, and your users would be >surprised by your exotic use of it. > >Why not pick any other character for end of chunk - double >newline, >Ctrl-S, pretty much anything but Ctrl-D? It's a waste of your >time to >fight a long-established standard. [...] GDB handles Ctrl-D differently. It doesn't close the input on the first one, it waits for the second one and then exits. After the first one it acts like you typed 'quit', which asks you if you really want to quit when there's a program still running. That's because gdb uses libreadline (or something along those lines) with cbreak, so it can intercept control characters without them getting interpreted by the terminal. This requires manual control of terminal functions, which is something outside the scope of readf(). (You'd be better off writing your own terminal handling from scratch, if that's what you want.) T Ah, nice to know. Thanks.
Re: Documentation Layout
On Wednesday, 28 March 2012 at 07:00:58 UTC, Brad Anderson wrote: [...] I've been trying to generate parsable ddoc output for use in an autocomplete for the search box (symbol names + short documentation excerpts for context). I had some luck but couldn't strip it down to the bare minimum information I wanted to extract so I got it in my head that I should try adding documentation to dmd's json output instead. I haven't attempted this yet. I think the search is very important. Right now someone basically has to tell you where which module certain structs/classes are in std.typecons has a lot of useful stuff but nobody would ever think to check there to find out where tuples or RefCounted are. Just yesterday I was very confused about why the documentation for 'recurrence' had gone missing but it turns out it's in std.range, not std.algorithm. [...] As long as normal documentation output is turned on, my Json improvements (https://github.com/D-Programming-Language/dmd/pull/813) will output the (unformatted) documentation comments associated with all top-level declarations. Take a look at that.
Re: IDE Support for D
On Friday, 6 April 2012 at 06:40:02 UTC, Gour wrote: Otherwise, I'm considering to use Geany and/or buy SublimeText2. I use Sublime Text 2, and it is a great editor. You can try it for free, there's just a nag dialog that opens occasionally.
Re: std.algorithms filter and string[]
On Wednesday, 11 April 2012 at 13:55:45 UTC, Russel Winder wrote:
I am having a dumb n00b moment, but I need to solve this 10
mins ago ;-)
immutable files = ( selector == 0 ) ? [ "." ] : filter ! ( (
string x ) { return x.isFile ; } ) ( sliceOfStrings ) ;
gives me the error:
Error: incompatible types for ((["."]) ?
(filter(sliceOfStrings))):
'string[]' and 'Result'
which in one universe is fine, but in my universe is a problem
as I
cannot see a way of properly creating a Result instance based
on the
array literal.
(I have a workaround, but I'd prefer to know the proper D idiom
for
this.
Thanks.
Use the array(...) function from std.array to convert "Result" to
the string[].
Re: Foreach Closures?
On Tuesday, 10 April 2012 at 02:24:31 UTC, Andrei Alexandrescu wrote: Would the JSON compiler output help? I made a pull request a while ago that gives a lot more JSON output (https://github.com/D-Programming-Language/dmd/pull/813). I'm willing to try to improve it to better meet the needs of an IDE, if anyone has any suggestions.
Re: Foreach Closures?
On Thursday, 12 April 2012 at 06:46:53 UTC, Jacob Carlborg wrote: I'm pretty sure that the JSON output can _never_ be enough for what we want to do. I agree with that, nothing will quite be the same as a full compiler-as-a-library (CAAL?). But in the meantime, there is a working compiler now, and isn't it better to get some kind of IDE-like functionality sooner rather than waiting for a long time with nothing?
Re: Notice/Warning on narrowStrings .length
On Friday, 27 April 2012 at 01:35:26 UTC, H. S. Teoh wrote: When I get the time? Hah... I really need to get my lazy bum back to working on the new AA implementation first. I think that would contribute greater value than optimizing Unicode algorithms. :-) I was hoping *somebody* would be inspired by my idea and run with it... I actually recently wrote a lexer generator for D that wouldn't be that hard to adapt to something like this.
Re: export extern (C) void Fun Error
On Friday, 27 April 2012 at 13:02:56 UTC, 拖狗散步 wrote: On Friday, 27 April 2012 at 01:21:56 UTC, Trass3r wrote: export c callback fun: alias void function(int id) ConnectedCallBack; alias void function(int id, void* data, int len) ReadCallBack; add extern(C) to be safe Thank, Trass3r! Finally correct, why have to export these two? You specified the C calling convention with UnmanagedFunctionPointer(CallingConvention.Cdecl), and extern(C) means use the C calling convention. Otherwise they'll be expecting a function using the D calling convention, which is incompatible.
Re: Cross module version specs
What about a templated module? module test(bool option1, T); Imported like this: import test!(true, Foo); It could act like the entire module was wrapped in a template, and the import would become: import test; mixin test.test_template!(true, Foo);
Re: Cross module version specs
On Friday, 27 April 2012 at 20:26:38 UTC, Dmitry Olshansky wrote: I would rather see this as import test with specified version identifiers. import test!(some_version); //imports module but treats it contents as if with "version = some_version;" added at the top of it This is inconsistent with the syntax and the way templates work in the rest of the language, as well as being a lot less flexible. It wouldn't be hard to mixin a string built from a list of identifiers passed in to set those versions.
Re: Why typedef's shouldn't have been removed :(
On Saturday, 5 May 2012 at 23:41:52 UTC, Mehrdad wrote:
That's *such* a lame question...
Even if I _couldn't_ tell you a reason, that'd still be a lame
question, because the *entire point* of reflection is to access
type information information about the program... if for nothing
other than printing it out for the user.
But it's more than that: it's the same darn reason why you need
to distinguish between
void* and HWND -- it's an ERROR!
In other words, this must NOT compile!
auto call(F, T...)(F func, T args) { return func(args); }
void test(uint) { }
void main() { call!(typeof(&test), size_t)(&test, 1); }
If you're still asking "why shouldn't it compile" then you
should
look up what "type safety" means.
That doesn't compile on x86_64.
The point of size_t is to be the native word-sized integer for
the platform, and it does exactly that.
Re: Why typedef's shouldn't have been removed :(
I understand you're frustrated, but you don't need to be so
hostile. I agree with most of what you've said on this thread.
And just because I made a short comment doesn't mean I don't know
about std.stdint, sizediff_t, etc. My point was to say that
size_t is supposed to be the size of the architecture's word. I
said nothing about it being the "fastest" type or even whether it
was useful . I would be very interested if you have a better
solution for the integer typing/naming problem.
There definitely needs to be way to define a type that can't
implicitly cast to its base type. The problem is that the
original typedef did do implicit casting away, and that has
potential to cause confusion when porting from C or D1. I don't
see that as much of a problem, but others might.
On Sunday, 6 May 2012 at 02:25:54 UTC, Mehrdad wrote:
The point of size_t is to be the native word-sized integer for
the platform
"Native word-sized integer" is such a blurry term, but of course
you
wouldn't know this without understanding why C has a gazillion
"native" integer types... (hint: if you're trying to justify
these with today's x86 processors, you're already on the wrong
track)
The point of size_t is for it to be able to represent the size
of
something. That's all.
The point of sizediff_t is for it to be able to represent the
difference between two size_t's. That's all.
The point of ptrdiff_t is for it to be able to represent the
difference between two pointers. That's all.
Those three need NOT be the same size on the same machine, and
they need NOT be the same as the "fastest" integers on any
platform.
That's the whole point of std.stdint, in case you hadn't heard
of
it.
That doesn't compile on x86_64.
I can't tell if you're missing my point or what...
In case that was unclear:
* I'm saying that shouldn't compile on *ANY* platform.
What you're saying is like saying "dchar[] function()" should be
interchangeable with "uint[] function()" just because they're
the same data on the same
platform.
Or like saying class Bar { } and class Foo { } should be
interchangeable because there's no actual difference between
them.
Or like saying "HWND function()" and "HANDLE function()" and
"void* function()" should be
interchangeable because they're all the same anyway.
Kind of silly IMO.
Re: Why typedef's shouldn't have been removed :(
On Sunday, 6 May 2012 at 03:28:32 UTC, Mehrdad wrote: Right, but what I was saying was that that *isn't* what it's meant to be! It's just a *size* type, not a *word* of any kind... (think about systems with interleaving pointers, for example, x86 with segmentation -- the notion of a "word" isn't so obvious anymore, when denoting sizes) Yeah, figuring out what to name something is always a challenge, and the huge variety and complexity of modern, and even not-so-modern processors doesn't help at all. There definitely needs to be way to define a type that can't implicitly cast to its base type. The problem is that the original typedef did do implicit casting away, and that has potential to cause confusion when porting from C or D1. I don't see that as much of a problem, but others might. Yeah, I still don't understand what the "potential to cause confusion" was. Was it *actually* causing a significant problem, or was it just a "potential" problem? The issue is if someone new to D2 is porting code from C or D1, they would get all kinds of weird errors caused by using typedef instead of D2's alias and trying to do math or expecting implicit casting to work. But D2 is a different language, with different syntax and semantics. Anyone expecting copied C to "just work" in D2 is expecting a miracle, but that's not to say we can't try to make it as easy as possible. IMO, alias is a much better name than typedef, which is quite generic because technically any struct, class, or even function declaration is defining a new type. But adding a new keyword is ugly, assuming you can think of a good one, so typedef is probably the best choice. The only other alternative is reusing existing keywords, but I can't even think of a good choice. Does any of static/const/immutable/etc. alias sound good to anyone?
Re: Optional parameters referring to previous parameters?
On Thursday, 10 May 2012 at 00:16:52 UTC, Mehrdad wrote:
Is this possible/should it compile?
If not, should I make an enhancement request for it? It's been
something that would've been useful in a ton of situations for
me...
void process(R)(R items, size_t maxCount = items.length)
{
}
Have you tried it?
I bet this isn't possible currently, but do open an enhancement
request if it isn't. It's going to be a bit tricky to implement,
but I like it.
