Re: The best programming advice I ever got
2012/8/29 Andrei Alexandrescu seewebsiteforem...@erdani.org: Not directly related to D, but hopefully a hook :o). http://www.informit.com/articles/article.aspx?p=1945828 Andrei Loved it! Torarin
Re: What guarantees does D 'const' provide, compared to C++?
2012/8/17 Jonathan M Davis jmdavisp...@gmx.com On Friday, August 17, 2012 02:32:01 Mehrdad wrote: C++ makes no such guarantees, because you're free to cast away const and modifiy objects Not correct, as far as I understand. C++ only lets you cast away _const references_ to _mutable_ objects. If the object happens to have been const _itself_, then that's undefined behavior. Well, then our understandings on the matter conflict, and I don't know for certain which of us is correct. - Jonathan M Davis The C++ standard, section 7.1.6.1: Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior. Torarin
Re: const ref and rvalues
2012/2/16 Trass3r u...@known.com: I posted this question several times already and no answer yet, why is allowing temporaries bind to ref const params bad again? To give you the option, I think. const ref doesn't bind to r-values, while const auto ref does. Torarin
Re: typedef deprecated - now what ?
2011/12/30 Stephan s...@extrawurst.org: On 30.12.2011 12:09, Trass3r wrote: is there a template or something in phobos to get the same typesafe behaviour of good old typedef ? I've brought this up several times. People just don't give a shit. http://d.puremagic.com/issues/show_bug.cgi?id=5467 thats too bad. pull request looks good. i voted for the ticket, but i guess that no one gives shit about that either :( Sure they give a shit. :-) I think Andrei is currently looking into ProxyOf for a new reference-counting type constructor. Torarin
Re: A nice way to step into 2012
2011/12/27 Joshua Reusch yos...@arkandos.de:
Am 27.12.2011 05:25, schrieb Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
Andrei
-
import std.algorithm;
void main() {
auto arr = [0, 5, 4, 3, 2, 1];
sort!((a, b) = a b)(arr);
}
-
$ ./dmd lambda_test
dmd: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *)
((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk,
fd old_size == 0) || ((unsigned long) (old_size) = (unsigned
long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *
(sizeof(size_t))) - 1)) ~((2 * (sizeof(size_t))) - 1)))
((old_top)-size 0x1) ((unsigned long)old_end pagemask) == 0)'
failed.
$
This also works with other functions from std.algorithm.
Did you do a clean before compiling? I forgot, and got the same error.
Torarin
2.057 regression and Result structs in std.algorithm
Some code using std.algorithm.filter broke today when I updated dmd.
Here's a test case:
-
import std.stdio, std.algorithm;
void main() {
writeln(filter!a != 'r'(Merry Christmas!));
}
Compiling with -inline gives:
/src/phobos/std/algorithm.d(1120): Error: function
std.algorithm.filter!(a != 'r').filter!(string).filter is a nested
function and cannot be accessed from formatValue
This reduced test case gives a clue as to what is going on:
-
auto fun()
{
struct Result {
this(int u) {}
auto bar() {
return Result(0);
}
}
return Result();
}
void main() {
auto t = fun();
auto a = t.bar();
}
-
Compiled with -inline:
t.d(7): Error: function t.fun is a nested function and cannot be
accessed from main
It seems what is happening is that bar is being inlined in main, but
dmd doesn't know where to get the new fun.Result's context pointer
from.
I'll file a bug report on this, but it made me wonder why
std.algorithm has so many non-static Result structs. Would it be a
good idea to make them static, where possible?
Torarin
Re: D Programming Language Specification ebook
2011/7/5 Andrei Alexandrescu seewebsiteforem...@erdani.org: It's whom :o). Andrei Are you sure? The people in people ... are complete idiots are the subjects of the sentence, so surely the subjective case of who is appropriate? Torarin
Re: D brand identity repository
2011/7/3 James Fisher jameshfis...@gmail.com: On Sat, Jul 2, 2011 at 10:32 PM, Jimmy Cao jcao...@gmail.com wrote: The mockup looks pretty good. I think the current D website should incorporate the idea of having those big tab-like links up at the top. See: http://eegg.github.com/d-brand/mockup.png http://ironpython.net/ http://cobra-language.com/ Right now there's just empty space. Sure thing. Updated http://eegg.github.com/d-brand/mockup.png, now with: - jumbo tabs - code sample - download links WRT the code sample, I think I remember seeing somewhere a web-hosted D installation? This for Go is one of my favourite features of their site (shame about the language itself). Such a thing for D would be a big attraction. Jumbo tabs great. Open Sans is pretty. I miss the colors in this: http://eegg.github.com/d-brand/d-logo-11.png. I even like the font you used on that one, but I don't know how well it would work in combination with Open Sans. I think the code sample should go in the body of the page. Can you try one with the three colored celestial bodies by themselves and The D Programming Language more prominently sized in the header? You're doing great work with this! Torarin
Re: D brand identity repository
2011/6/30 James Fisher jameshfis...@gmail.com: On Thu, Jun 30, 2011 at 8:02 PM, Steven Schveighoffer schvei...@yahoo.com wrote: Also, that looks like a sideways snowman :) Here, have some cartoon craters https://github.com/eegg/d-brand/raw/master/d-logo-9.png I love this! I normally prefer minimalistic logos, like Haskell's, but this one is so fun. It's balanced and it works. Torarin
Re: Flag proposal
2011/6/10 Andrei Alexandrescu seewebsiteforem...@erdani.org: On 6/10/11 1:52 PM, Robert Clipsham wrote: On 10/06/2011 19:06, Andrei Alexandrescu wrote: On 6/10/11 12:42 PM, Robert Clipsham wrote: On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. This is not half-baked. It's pretty much it. My choice of wording was poor, sorry. Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I agree it's more legible. The crucial question is whether the added legibility warrants adding a new feature to the language. The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. void foo(bool param, bool otherParam, bool thisOneIsntRequired = false); Call it with or without named parameters, two are required, one is not. foo(otherParam: true, param: false); foo(true, false); foo(otherParam: true, param: false, thisOneIsntRequired: true); Would all be valid. The second call is problematic because it still allows bad style in calls. Andrei I agree, introducing a syntax for required named parameters sounds like it would entail baggage of similar weight. Torarin
Re: How about a Hash template?
2011/4/29 Alexander aldem+dm...@nk7.net: On 28.04.2011 21:46, Timon Gehr wrote: Why is 'in' not currently defined on arrays? To me it seems like a left-out that should be fixed, because it has quite obvious and useful semantics. +1. It would be very useful and convenient this way, especially if search will be optimized to series of comparisons for small item count. Perhaps we should file a feature request? :) /Alexander This has been discussed before, see: http://www.mail-archive.com/digitalmars-d@puremagic.com/msg38779.html Torarin
Re: [Article Context, First Draft] Concurrency, Parallelism and D
2011/4/8 dsimcha dsim...@yahoo.com: Here's a first draft of an article on D's approaches to concurrency and parallelism for D's article contest. It's not an official submission yet, but feedback would be appreciated. http://davesdprogramming.wordpress.com/2011/04/07/7/ A very good article! And I like that you linked to other articles that go into more detail on relevant subjects. I wouldn't mind a couple more examples. Torarin
Re: image processing in D
2011/4/4 Emil Madsen sove...@gmail.com: And a more specific question; say one wants to blur a picture with Gaussian blur, how would D ranges deal with the 2d array? foreach (r; image.rows) convolute1d(r, gaussianKernel); foreach (c; image.cols) convolute1d(c, gaussianKernel); Torarin
Re: [GSoC Proposal draft] High-Level Networking
2011/4/7 Jonas Drewsen jdrew...@nospam.com: On 07/04/11 00.32, Max Klyga wrote: OK, I've absorbed enough informtion to transform my thoughts in the second proposal draft. I'll be posting it direcltly to GSoC website and correct it, if necessary. Proposal is situated here: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/neku42/1 Comments are welcome. Seems good to me. Some comments: You mention that a reactor will probably be used for implementing the proactor. On windows it really doesn't make sense to do this it think. Instead overlapped IO should be used since it maps very well with the proactor pattern. I also suggest that you specify which OSes you will make support for. If that is only e.g. linux then building on reactors is the right way to go as you've planned. /Jonas Indeed it looks good! You can use the reactor pattern on Windows as well, but several sources say that overlapped IO is more efficient, and it probably is cleaner. But it's still nice to have a reactor that wraps select and friends, and then specialize the individual proactors as needed. Was that what you were thinking, Max? Torarin
Re: Jonas Drewsen has been accepted as a GSoC 2011 mentor for Digital Mars
Congratulations, Jonas! Torarin
Re: [GSoC Proposal draft] High-Level Networking
2011/4/4 Max Klyga max.kl...@gmail.com: Thanks to everyone who provided feedback! I'll post my proposal update tomorrow. I'm looking forward to it too! I've done a fair amount of research on these topics and given networking in D a lot of thought. I'd prefer the standard library's socket interface to be more low level than it is today, and to have a socket type that provides non-blocking IO transparently through fibers. This enables both generic protocol implementations that can handle several types of concurrency, and efficient parsers using buffered input ranges. I also think the library should offer it's own event loop instead of linking to libev or libevent, which have their weaknesses in such a context. For instance, you can't simply hand over garbage collected objects to them, which is unfortunate given the usefulness of closures for handling events. I also think a lower-level API than Boost ASIO is wise, because one may need to use novel and platform-specific optimizations like linux splice, a must for efficient file servers. As I mentioned, I have started implementing some of this. Would you be interested in pairing up with me on some parts of the project? Best regards, Torarin
Re: GSoC: Containers and Ranges
2011/4/2 Christian Hotz-Behofsits chris.hotz.behofs...@gmail.com: Hi everyone! I applied to GSoC 2011 to enhance D's container landscape. For that reason I read a lot about D and it's given containers, because I used it once, but not quite extensive and there is one speciality I don't understand yet - ranges. All in all the documentation is really good, but I wasn't able to find adequate descriptions or suitable examples - Can you help me ? Are ranges only conjugate parts of the given container? Or like the C++ iterators? Are there comparable structs in other languages? even if I don't get the chance - I take it serious :-) If you haven't read it already, I recommend Andrei Alexandrescu's great article introducing ranges: http://www.informit.com/articles/article.aspx?p=1407357 Torarin
Re: Asynchronicity in D
2011/3/31 Jonas Drewsen jdrew...@nospam.com: On 31/03/11 21.19, Torarin wrote: I'm currently working on an http and networking library that uses asynchronous sockets running in fibers and an event loop a la libev. These async sockets have the same interface as regular Berkeley sockets, so clients can choose whether to be synchronous, asynchronous or threaded with template arguments. For instance, it has HttpClient!AsyncSocket and HttpClient!Socket. Torarin Very interesting! Do you have a github repos we can see? /Jonas I just put one up: https://github.com/torarin/net Here's an example: https://github.com/torarin/net/blob/master/example.d Torarin
Re: null Vs [] return arrays
2011/4/1 Regan Heath re...@netmail.co.nz: On Mon, 28 Mar 2011 17:54:29 +0100, bearophile bearophileh...@lycps.com wrote: Steven Schveighoffer: So essentially, you are getting the same thing, but using [] is slower. It seems I was right then, thank you and Kagamin for the answers. This may be slightly OT but I just wanted to raise the point that conceptually it's nice to be able to express (exists but is empty) and (does not exist). Pointers/references have null as a (does not exist) value and this is incredibly useful. Try doing the same thing with 'int' .. it requires you either use int* or pass an additional boolean to indicate existence.. yuck. I'd suggest if someone types '[]' they mean (exists but is empty) and if they type 'null' they mean (does not exist) and they may be relying on the .ptr value to differentiate these cases, which is useful. If you're not interested in the difference, and you need performance, you simply use 'null'. Everybody is happy. :) R For associative arrays it certainly would be nice to be able to do something like string[string] options = [:]; so that functions can manipulate an empty aa without using ref. Torarin
Re: Asynchronicity in D
I'm currently working on an http and networking library that uses asynchronous sockets running in fibers and an event loop a la libev. These async sockets have the same interface as regular Berkeley sockets, so clients can choose whether to be synchronous, asynchronous or threaded with template arguments. For instance, it has HttpClient!AsyncSocket and HttpClient!Socket. Torarin
Re: [OT] Webpage design and Name That Color!
warm grey
appendToFront semantics
I've been experimenting with Andrei's buffered input range and noticed that appendToFront(size_t n) may benefit from a slightly different definition. Andrei describes it as appending at most n elements to the front. But if you change that to at least, the range can ask the underlying stream to also fill any unused space in the buffer. If unused space is available before doing the append, this can also be achieved by doing appendToFront(0) until you reach the desired front.length. But if that leads to a move of buffered data, it becomes less efficient than it could be. The change means you would lose the ability to limit the amount read from the underlying stream, which could be useful for a e.g. a protocol switch, but I'm inclined to think that's less important than the efficiency of the common case. Did I miss the reason why this doesn't work well? Torarin
Re: appendToFront semantics
2011/2/15 Adam Ruppe destructiona...@gmail.com: One problem with at least is it might have to wait for two packets to come off the network interface; could be fairly slow. The at most means it will take whatever is available without overflowing your buffer - it will never wait if there is any data available. But isn't the reason you're supplying a value to appendToFront that you do want a specific amount? If not, you can use appendToFront(0) until you get what you want. Torarin
Re: appendToFront semantics
2011/2/15 Andrei Alexandrescu seewebsiteforem...@erdani.org: On 2/15/11 12:10 PM, Adam Ruppe wrote: One problem with at least is it might have to wait for two packets to come off the network interface; could be fairly slow. Another is that the stream may end... so there's no guarantee. Andrei If the stream ends it would return short. Anyway, my main point was to allow it to read more than n elements. So if you give it the definition try to append n elements or more it caters for the don't block and don't consume more memory than this situation as well. Torarin
Re: higher-order funcs for ranges (with usual interface)
If you want to use an interface as a concept, you can take kenji's
adaptTo module and add this:
template conformsTo(T, Interfaces...)
{
enum conformsTo = AdaptTo!Interfaces.hasRequiredMethods!T;
}
and use it like this
void draw(T)(T shape) if (conformsTo!(T, Shape, Drawable))
This will of course only work for methods, not properties or aliases,
so you still need constraints in some cases.
Torarin
Re: buffered input
2011/2/7 Robert Jacques sandf...@jhu.edu: On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 2/6/11 6:01 EST, Tomek Sowiński wrote: Nick Sabalausky napisał: discard and fetch? I like that. What's missing is the part that they refer to front. Maybe discardFromFront() and fetchToFront()? But then I like discardFromFront() and appendToFront() better - the latter is about as long and more informative. Don't forget that these are relatively rarely used. Andrei Actually, I don't think these functions would be relatively rarely used. I don't see that many people using a buffered input's popFront. Instead I see shiftFront in its place and an appendToFront call has to be made whenever buffer.front.empty. Why not popFront if empty? Maybe you could use appendToFront if you knew that you needed to expand the stream's buffer, but that doesn't sound like a common case. Torarin
Re: buffered input
2011/2/7 Andrei Alexandrescu seewebsiteforem...@erdani.org: On 2/6/11 9:47 PM, Torarin wrote: 2011/2/7 Robert Jacquessandf...@jhu.edu: On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 2/6/11 6:01 EST, Tomek Sowiński wrote: Nick Sabalausky napisał: discard and fetch? I like that. What's missing is the part that they refer to front. Maybe discardFromFront() and fetchToFront()? But then I like discardFromFront() and appendToFront() better - the latter is about as long and more informative. Don't forget that these are relatively rarely used. Andrei Actually, I don't think these functions would be relatively rarely used. I don't see that many people using a buffered input's popFront. Instead I see shiftFront in its place and an appendToFront call has to be made whenever buffer.front.empty. Why not popFront if empty? Maybe you could use appendToFront if you knew that you needed to expand the stream's buffer, but that doesn't sound like a common case. Torarin Exactly. Consider line continuations. Most of the time you read one line at a time and everything goes swell. On occasion you'll have a line continuation convention (line ends with a backslash, unmatched quote etc.) and you need to expand the current buffer to gobble the next line. Andrei Yes, it's really convenient. You don't have to start messing with your own buffer, and you avoid the temptation of doing one-element reads. What seems more unlikely is using it on an empty front, though. Torarin
Re: buffered input
2011/2/7 Robert Jacques sandf...@jhu.edu: On Sun, 06 Feb 2011 21:47:48 -0500, Torarin torar...@gmail.com wrote: 2011/2/7 Robert Jacques sandf...@jhu.edu: On Sun, 06 Feb 2011 10:43:47 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 2/6/11 6:01 EST, Tomek Sowiński wrote: Nick Sabalausky napisał: discard and fetch? I like that. What's missing is the part that they refer to front. Maybe discardFromFront() and fetchToFront()? But then I like discardFromFront() and appendToFront() better - the latter is about as long and more informative. Don't forget that these are relatively rarely used. Andrei Actually, I don't think these functions would be relatively rarely used. I don't see that many people using a buffered input's popFront. Instead I see shiftFront in its place and an appendToFront call has to be made whenever buffer.front.empty. Why not popFront if empty? Because even reading UTF-8 requires more than 1-byte of information. Basically, any routine that processes a raw stream is going to have to handle the case where what they're processing straddles the buffer boundary. Now, if the routine wraps the raw stream in some higher-order range, such as byLine, which guarantees them that none of their inputs straddle, great. But it would be negligent to neglect those coders writing the higher-level ranges. But popFront also reads more than 1 byte. Unless you call appendToFront with a larger value than the current buffer size, unless I have misunderstood, they should end up doing the same thing. Torarin
Re: buffered input
2011/2/5 Andrei Alexandrescu seewebsiteforem...@erdani.org: I hereby suggest we define buffered input range of T any range R that satisfies the following conditions: 1. R is an input range of T[] 2. R defines a primitive shiftFront(size_t n). The semantics of the primitive is that, if r.front.length = n, then shiftFront(n) discards the first n elements in r.front. Subsequently r.front will return a slice of the remaining elements. 3. R defines a primitive appendToFront(size_t n). Semantics: adds at most n more elements from the underlying stream and makes them available in addition to whatever was in front. For example if r.front.length was 1024, after the call r.appendToFront(512) will have r.front have length 1536 of which the first 1024 will be the old front and the rest will be newly-read elements (assuming that the stream had enough data). If n = 0, this instructs the stream to add any number of elements at its own discretion. This is really cool. I realise now that appendToFront fills the gap in the design providing only shiftFront/advance. I also thought their names were well-chosen. Torarin
Re: const/immutable member functions
2011/1/24 bearophile bearophileh...@lycos.com:
What other people think about this situation? Do you want const/immutable to
be required on the right, or do you prefer the current situation, or do you
prefer some other solution?
If const is required to go on the right, what do you do if you want to
mark a bunch of functions const inside {}?
Torarin
Re: const/immutable member functions
2011/1/24 Simen kjaeraas simen.kja...@gmail.com:
The suggestion is only for const alone on the left-hand side. const: and
const{} would not be affected by such a change.
You're right, it's not confusing at all. It makes perfect sense for
function attributes to go on the right. But then I'd like all of them
to go there, like Jonathan suggested.
Torarin
Re: const/immutable member functions
2011/1/24 foobar f...@bar.com:
This problem happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.
Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable:
attribute funcName inputParams - outputParams { body }
This is the typical functional language design.
It is arguably more consistent to have the return type come first, as
in variable declarations:
int a = 4;
int foo() { return 5; }
Both foo() and a are now of type int.
Torarin
Re: Opt-out closures
2011/1/23 Sean Eskapp eatingstap...@gmail.com:
I want to be able to access the enclosing scope, but NOT after the function
has
exited; I should have the option of accessing the enclosing scope, but at the
cost
of making my delegate not a closure.
Until we have a dedicated syntax for it, I think you can use this hack:
import std.traits;
auto scopeDelegate(D)(scope D d) if (isDelegate!D)
{
return d;
}
int main()
{
StructWithDtor s;
trustedFunction(scopeDelegate({s.a = 5;}); // No heap allocation
}
Torarin
Re: more naming
2011/1/22 Andrei Alexandrescu seewebsiteforem...@erdani.org: OK, so we have replace(haystack, needle, nail) which replaces _all_ occurrences of needle in haystack with nail. How would you call a function that replaces only the _first_ occurrence of needle with nail? Must be a distinct function, not a runtime parameter to the existing function. This is because the function that replaces only one occurrence only requires nail to be an input range. Andrei It sounds like the current replace should be named replaceAll. Torarin
Re: Python's partition
Divide? As in dividing a pie chart. Torarin
Re: more naming
2011/1/22 Andrei Alexandrescu seewebsiteforem...@erdani.org: That's what I'm fearing - changing current replace to replaceAll and adding replace with the meaning of replaceFirst would silently change the semantics of existing code. Andrei Yeah, I see that problem. I'm just so used to replace first being the default in text editors, and then you have a replace all button if you want to replace everything. That also seems to be Walter's reasoning in std.typetuple.
Re: emscripten
2010/12/15 Adam D. Ruppe destructiona...@gmail.com: 4) The scripts might fetch the message after the one you click on as well, just ajax getting the next document in line then doing nothing with the result. My server code would be configured to send the proper cache headers, meaning when you click the link to actually view it, it is pre-loaded in the cache, and thus loads instantly. A lot of websites do it for images, why not documents too? This would keep the user visible latency to a minimum while browsing messages. Gmail does preload all unread messages plus the last message in each thread. It also preloads the first few words of every message as a preview. I'll give you that it could have fetched everything, though. Torarin
Re: C#'s greatest mistakes
2010/11/27 Andrei Alexandrescu seewebsiteforem...@erdani.org: We use template constraints for that kind of stuff. Andrei Yes, and that's great, but is there a way to check whether a template argument matches a defined interface?
Re: C#'s greatest mistakes
2010/11/28 Jonathan M Davis jmdavisp...@gmx.com:
If you have a set
of functions that are expected to be there (for instance, to verify that the
given type is a certain type of range), then just create template which checks
for each of the functions that are supposed to be there and use the template (
e.g. isForwardRange!T ). Interfaces and structs don't have anything to do with
each other.
Yes, that works, and you end up with this:
template isSomething(T)
{
enum bool isSomething = is(typeof(
{
int ret = T.foo(5);
string ret2 = T.bar();
T.write();
}()));
}
I don't see what's so wrong with being able to do:
interface Something
{
int foo(int);
string bar();
void write();
}
if (Implements!(Something, T))
Thanks for the link, BLS, I'll see if I can make it work.
Re: C#'s greatest mistakes
2010/11/28 Jonathan M Davis jmdavisp...@gmx.com:
You could theoretically create a template which verified that a struct had the
same functions that an interface required for a class to implement it, but
since
a struct can't implement it, it's just confusing and unnecessary to add a
useless interface into the mix. The struct can't implement it.
I think it's a matter of taste whether it's confusing or not. I'd say
it looks better than the is(typeof({}())) combo, and in some ways it's
less confusing. Implement! may be a bad name, because structs will of
course not implement the interface in the traditional sense. The
interface is just the concept.
Torarin
Re: C#'s greatest mistakes
2010/11/28 Michel Fortin michel.for...@michelf.com:
Well, if you consider the previously discussed 'adaptTo' function template,
all types can be adapted to an interface (via a template-generated wrapper
class). So implements for structs isn't too far off, as you can use the
struct to implement the interface via 'adaptTo'.
Actually, adaptTo already uses such a template internally. So I would
suggest to just add this:
template conformsTo(T, Interfaces...)
{
enum conformsTo = AdaptTo!Interfaces.hasRequiredMethods!T;
}
Re: C#'s greatest mistakes
Static interfaces (same thing as c++ 0x's ditched concepts) seem very useful. Did you consider them at some point? Torarin 2010/11/27 Walter Bright newshou...@digitalmars.com: Andrei Alexandrescu wrote: http://oredev.org/2010/sessions/c-s-greatest-mistakes A summary for those who don't want to sit through it: http://news.ycombinator.com/item?id=1942859
Re: Apache mod_d needs C to instantiate D interpreter?
2010/11/9 Andrei Alexandrescu seewebsiteforem...@erdani.org: People at Facebook told me that the adoption of D inside the company might be helped if they could simply write ?d ... ? to insert D code into a page. I'm not sure how difficult such a plugin would be to implement. Also, D code should be able to call PHP code (which is a bit less difficult than it seems because we use HPHP, a PHP to C++ translator). Andrei I got the impression that Facebook does not use Apache for serving php pages since Hiphop runs programs in their own server (using libev, I think)? And FastCGI is really just an awkward reincarnation of HTTP. So perhaps the optimal situation is to have D interface with the web not through a plugin, but rather through an HTTP server class. If necessary, it can then sit behind an Apache proxy.
Re: shorter foreach syntax - C++0x range-based for
Pilsy: D is as much Java++ as it is C+=2. Andrei: Java did a lot of things right (be they novel or not) that are present in D Even if Java did only a single thing right, it would be silly to not adopt it just to avoid embarrassment. Anyway, I think it's a nice syntax.
Re: Associative array .get with .init as default second argument
2010/10/18 bearophile bearophileh...@lycos.com: In what cases is this useful? Are you able to show me an example of situation where it is useful? Bye, bearophile Bearophile, I probably didn't make it very clear, so I'll try again: Now: if (headers.get(transfer-encoding, ) == chunked) More appealing in my opinion: if (headers.get(transfer-encoding) == chunked) In other words: Does this key-value pair exist? Another example from the HTTP domain: if(headers.get(connection, ) == close)
Associative array .get with .init as default second argument
The AA .get function is defined like this:
Value get(Key key, lazy Value defaultValue)
{
auto p = key in *cast(Value[Key]*)(p);
return p ? *p : defaultValue;
}
Can we also have an overload that uses Value's init value as fallback?
That would simplify checks like this:
if (headers.get(transfer-encoding, ) == chunked)
if (headers.get(transfer-encoding) == chunked)
This is what STL map's operator [] does, and I think it's handy. It
only requires the addition of this overload:
Value get(Key key)
{
auto p = key in *cast(Value[Key]*)(p);
return p ? *p : Value.init;
}
It would also make these kind of accesses more efficient, since you
skip the lazy delegate.
Re: Associative array .get with .init as default second argument
The useful situation is when you care only about the presence of a certain value in a given key. I actually gave an example of it.
Re: duck!
I feel as and to are too similar, they could both be interpreted as simple casting for example.
Re: in everywhere
2010/10/7 Andrei Alexandrescu seewebsiteforem...@erdani.org:
In the end I figured there was only _one_
quadratic operation - appending to a vectorsize_t that held document
lengths. That wasn't even the bulk of the data and it was the last thing I
looked at! Yet it made the run time impossible to endure.
From sgi's stl vector:
void push_back(const _Tp __x) {
if (_M_finish != _M_end_of_storage) {
construct(_M_finish, __x);
++_M_finish;
}
else
_M_insert_aux(end(), __x);
}
How is this quadratic, let alone linear?
Re: Am I doing it wrong?
2010/10/3 Emil Madsen sove...@gmail.com:
Well the result is assigned to an immutable int, shouldn't that be a compile
const too?
Immutable means that the variable, or the memory it points to, will
not change. You can still assign run-time values to it:
void main(string[] args)
{
immutable string a = args[0];
writeln(a);
}
Re: Am I doing it wrong?
2010/10/3 Emil Madsen sove...@gmail.com: ah ofc! I shoulda know :) - So I were doing it wrong :) Say I'm doing that enum a = calcPrimes(); then a will be an enum with 1 element, that I can use as an int right? Yes, effectively you are declaring an anonymous enum with one element. By default an int.
Re: The Wrong Stuff
2010/9/24 Jonathan M Davis jmdavisp...@gmx.com: However, we're not going to double the number of keywords that we have, and the @ syntax has allowed us to remove some keywords and will allow us to add more stuff later without having to add keywords. Why are attributes not considered keywords? Because the compiler doesn't care about them?
Re: The Wrong Stuff
2010/9/25 Jonathan M Davis jmdavisp...@gmx.com: Part of the point of attributes was to make it so that they weren't keywords and therefore didn't make the list of keywords any longer. If they make the attribute list longer, what do you gain from making the keyword list shorter, other than @-ifying the keywords?
Re: The Wrong Stuff
2010/9/25 Jérôme M. Berger jeber...@free.fr: Basically, all it does is defining a namespace for keywords. Since you can't define identifiers with an @, then whenever Walter wants to add a new keyword, he only has to pick one that start with @ to make sure that he won't break anyone's code. I see. It guess it's good idea to have a namespace for lesser-used keywords to avoid naming conflicts. My first impression was that @ttributes were specialized comments, since the absence of @property doesn't stop you from using property syntax, and @disable just produces a nicer error message from the compiler.
Re: std.mixins
TDPL says it should work for any type. http://d.puremagic.com/issues/show_bug.cgi?id=3382 2010/9/1 Nick Sabalausky a...@a.a: dsimcha dsim...@yahoo.com wrote in message news:i5jtdn$1g4...@digitalmars.com... Isn't this a core language feature that's in the spec but is only currently implemented for arrays? I thought eventually uniform function call syntax was coming for classes and structs, too. I've been really wishing for a long time that would actually happen. It's annoying enough not to be able to do it for most types, but then the fact that it's special-cased at all is a bit of a bizarre inconsistency.
Re: std.mixins
It says: If a.fun(b, c, d) is seen but fun is not a member of a's type, D rewrites that as fun(a, b, c, d) and tries that as well. So I guess it's possible it won't work with numerical types because they can never have members. 2010/9/1 Philippe Sigaud philippe.sig...@gmail.com: On Wed, Sep 1, 2010 at 20:59, Nick Sabalausky a...@a.a wrote: Torarin torar...@gmail.com wrote in messageTDPL says it should work for any type. http://d.puremagic.com/issues/show_bug.cgi?id=3382 /me squeals with excitement like a schoolgirl Any type, really? Even the basic built-in types, not only class/struct? That'd fun.
Re: std.mixins
2010/9/1 Philippe Sigaud philippe.sig...@gmail.com: I just tried this: int i; writeln(i.max); // writes int.max ! So it seems you can access the type properties through a value of that type. Man, I learnt two new things in two minutes... Yay, looks pretty good, then! :)
Re: [Slight OT] TDPL in Russia
So reviews are useless? 2010/8/31 BCS n...@anon.com: Hello Kagamin, dsimcha Wrote: Of course everyone thinks ~60-70% of what Hollywood puts out is crap. The problem is that everyone thinks that about a **different** ~60-70% because different movies cater to different niches. Having a single centralized this movie is crap authority is how dictatorship works. Producing movies even if only a minority thinks they're worth watching, as long as that minority can pay enough to make it profitable is how capitalism works. I know, there's a niche for crap. You can replace the question of quality with question of profit. I call it ignorance. Everything you like, someone else thinks is crap and someone else thinks is offensive. Same goes for me. And everyone else. Any standard chosen by /a man/ is arbitrary and not inherently any better than any other. -- ... IXOYE
Re: [Slight OT] TDPL in Russia
2010/8/31 BCS n...@anon.com: Hello Torarin, So reviews are useless? Without context, yes they are useless. With context, your just looking at correlation: i.e we like/dislike the same things. I can understand the premise of the view that art cannot be quality-assessed, but I think there are still clichés, formulas, poor execution like bad acting, unrealistic dialog, etc., that can be pointed out by experienced reviewers. Torarin
Re: std.algorithm move() struct emptying
Currently you can take its address, so doesn't that mean that it's an lvalue? 2010/8/30 Jonathan M Davis jmdavisp...@gmail.com: On Sunday, August 29, 2010 11:51:51 Torarin wrote: Even in this case, or in some special case? Torarin 2010/8/29 Andrei Alexandrescu seewebsiteforem...@erdani.org: On 08/29/2010 12:00 PM, Torarin wrote: Hi, in std.algorithm move(), this is the operation used to set the source of a struct move to .init: static T empty; memcpy(source, empty, T.sizeof); Is there any particular reason why the more compact T.init is not used? T.init is not guaranteed to be an lvalue. Andrei T.init cannot be set. It's a fixed value. When you use it, you're typically going to be copying it to an lvalue or creating a temporary. Temporaries aren't lvalues. So, T.init can be assigned to an lvalue, but it isn't itself an lvalue. - Jonathan M Davis
Re: std.algorithm move() struct emptying
Yeah, I get the enum case, but what I forgot to mention is that the example from move() is enclosed in static if (is(T == struct)) Which makes me wonder what kind of struct would have an rvalue .init. Torarin 2010/8/30 Stanislav Blinov stanislav.bli...@gmail.com: You may be able to take address of what .init returns, but what Andrei meant by 'it is not guaranteed' means that this is not always the case. So basically, you should not rely on the cases when you can do that. That's why I was wrong, also. The case wasn't about temporaries at all :)
std.algorithm move() struct emptying
Hi, in std.algorithm move(), this is the operation used to set the source of a struct move to .init: static T empty; memcpy(source, empty, T.sizeof); Is there any particular reason why the more compact T.init is not used?
Re: std.algorithm move() struct emptying
Yes, you are right!
Looking at the assembly, T.init creates a struct on the stack.
2010/8/29 Stanislav Blinov stanislav.bli...@gmail.com
Torarin wrote:
Hi,
in std.algorithm move(), this is the operation used to set the source of a
struct move to .init:
static T empty;
memcpy(source, empty, T.sizeof);
Is there any particular reason why the more compact T.init is not used?
I may be wrong, but it seems that in this case T.init will yield a temporary,
while static T empty is 'always' there.
Consider:
struct S {}
void main()
{
writefln(%x, S.init); // prints one value
writefln(%x, S.init); // prints another value
static S s;
writefln(%x, s); // prints one value
writefln(%x, s); // prints the same value
}
Re: std.algorithm move() struct emptying
Even in this case, or in some special case? Torarin 2010/8/29 Andrei Alexandrescu seewebsiteforem...@erdani.org: On 08/29/2010 12:00 PM, Torarin wrote: Hi, in std.algorithm move(), this is the operation used to set the source of a struct move to .init: static T empty; memcpy(source, empty, T.sizeof); Is there any particular reason why the more compact T.init is not used? T.init is not guaranteed to be an lvalue. Andrei
Socket.shutdown() error handling
Perhaps Socket.shutdown() in std.socket should throw an exception in case of an error? Unlike close(), it may fail before you are done with the socket. One may, for instance, want to wait for a confirmation message from the client after sending the FIN packet with shutdown(SocketShutdown.SEND). If the client disconnected, POSIX shutdown() can inform you with erro ENOTCONN.
