Re: GSoC-2011 project:: Containers
I think that a doubly linked list is useful, actually it one should implement most things so that the can work on any object that has prev and next pointers, and give a templated default list wrapper. That is what I did for singly linked lists, and it works well. Often one wants to avoid allocating lot of small wrappers... About the containers I did propose the persistent ones, because they are useful, and currently there aren't any, whereas for more classic dcollection is there (even if not part of phobos). Fawzi On 30-mar-11, at 01:55, Jonathan M Davis wrote: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly- linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly- linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis
Re: GSoC-2011 project:: Containers
Am 30.03.2011 01:55, schrieb Jonathan M Davis: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis It may be feasible to enhance the single-linked list to support both single- and double linking, via an additional template-parameter "bool doubly" or something like that and some static-ifs in the implementation. I once created a simple single/double-linked queue for D1 like that. Cheers, - Daniel
Re: Review of std.net.isemail part 2
On 3/30/11 1:30 AM, Jesse Phillips wrote: Jacob Carlborg Wrote: I've made a few minor changes: * Renamed EmailStatusCode.Off -> None and On -> Any * Added and clarified the documentation for EmailStatusCode.Any and None * Updated the documentation Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: http://dl.dropbox.com/u/18386187/isemail.html -- /Jacob Carlborg I believe enum values are to be named lowercase first. EmailStatusCode.any I don't know what the style guide says about enum members but if that's the case I'll change the names to begin with lowercase. -- /Jacob Carlborg
Re: GSoC-2011 project:: Containers
On Mar 30, 11 16:18, Daniel Gibson wrote: Am 30.03.2011 01:55, schrieb Jonathan M Davis: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis It may be feasible to enhance the single-linked list to support both single- and double linking, via an additional template-parameter "bool doubly" or something like that and some static-ifs in the implementation. I once created a simple single/double-linked queue for D1 like that. Cheers, - Daniel It is always possible to combine types together with 'static if', but the structure and interface is sufficiently different that doubly-linked list should better be a separate type.
Re: GSoC-2011 project:: Containers
On 2011-03-30 01:18, Daniel Gibson wrote: > Am 30.03.2011 01:55, schrieb Jonathan M Davis: > > On 2011-03-29 14:50, dsimcha wrote: > >> == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article > >> > >>> The fancier stuff would be nice, but we don't even have a doubly-linked > >>> list yet. We should get the simpler stuff sorted out before we get > >>> particularly fancy, not to mention that it's usually the simple stuff > >>> that gets heavily used. > >> > >> For the most part I agree, but a doubly linked list might be **too** > >> simple. Linked lists are so trivial to implement that I'd tend to roll > >> my own that does exactly what I need with regard additional behavior on > >> insertion, etc. rather than wrapping a library solution to get these > >> features. > > > > A doubly-linked list is on the list of containers that every standard > > library should have or it's likely to be considered lacking. I can > > understand rolling your own for specific uses, but _I_ sure don't want > > to be doing that if I don't have to. If I want a doubly-linked list, I > > want to be able to just create a standard one and use it. C++, C#, and > > Java all have doubly-linked lists in their standard libraries. > > > > If no one else ever implements a doubly-linked list for Phobos, I'll > > probably do it eventually simply because it's one of the containers that > > is on the short list of containers that pretty much every standard > > library has. > > > > - Jonathan M Davis > > It may be feasible to enhance the single-linked list to support both > single- and double linking, via an additional template-parameter "bool > doubly" or something like that and some static-ifs in the implementation. > I once created a simple single/double-linked queue for D1 like that. To what end though? I don't think that that would save you much. While some of the implementation would be the same, so much of it would be different, that you'd practically have two complete types defined in one template. At that point, you might as well create a separate class/struct. It's just simpler to have them separate, and I don't see any real gain in combining them. Having both is great, since there are times that you want one and times when you want the other, but having both SList and DList (or whatever it would be called) as separate types makes sense. - Jonathan M Davis
Re: GSoC-2011 project:: Containers
Am 30.03.2011 10:27, schrieb KennyTM~: On Mar 30, 11 16:18, Daniel Gibson wrote: Am 30.03.2011 01:55, schrieb Jonathan M Davis: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis It may be feasible to enhance the single-linked list to support both single- and double linking, via an additional template-parameter "bool doubly" or something like that and some static-ifs in the implementation. I once created a simple single/double-linked queue for D1 like that. Cheers, - Daniel It is always possible to combine types together with 'static if', but the structure and interface is sufficiently different that doubly-linked list should better be a separate type. Is it? It's just a few additional functions and the functions do some additional stuff (mostly handling prev-pointers) for double-linked lists. Much of the single-linked list code can (probably) be reused - so why duplicate code?
Re: Review of std.net.isemail part 2
On 2011-03-30 01:27, Jacob Carlborg wrote: > On 3/30/11 1:30 AM, Jesse Phillips wrote: > > Jacob Carlborg Wrote: > >> I've made a few minor changes: > >> > >> * Renamed EmailStatusCode.Off -> None and On -> Any > >> * Added and clarified the documentation for EmailStatusCode.Any and None > >> * Updated the documentation > >> > >> Github: https://github.com/jacob-carlborg/phobos/tree/isemail > >> Docs: http://dl.dropbox.com/u/18386187/isemail.html > >> > >> -- > >> /Jacob Carlborg > > > > I believe enum values are to be named lowercase first. > > EmailStatusCode.any > > I don't know what the style guide says about enum members but if that's > the case I'll change the names to begin with lowercase. All names are camelcased. All type names begin with an uppercase letter, and all variables begin with a lowercase letter (with the possible exception of private member variables beginning with _ - but what's private to a class or struct isn't as critical as the public API regardless). enum values fall in the same camp as variables. We don't really have an actual document anywhere that lays out the style. Andrei has resisted the idea, though I don't think that he's entirely against it, so unfortunately, I don't think that there's currently anywhere that you can look it up. Discussions of the newsgroups have made the decisions on the naming conventions clear though, at least as long as you've paid attention and remember them, which obviously isn't going to happen for newer folks on the list, and unless you're regularly writing Phobos code and making sure that you follow the appropriate conventions, it's probably not all that hard to forget them if they're not what you'd do anyway. In any case, enum values follow the same style as normal variables - camelcased, beginning with a lowercase letter. - Jonathan M Davis
Re: GSoC-2011 project:: Containers
On Mar 30, 11 16:41, Daniel Gibson wrote: Am 30.03.2011 10:27, schrieb KennyTM~: On Mar 30, 11 16:18, Daniel Gibson wrote: Am 30.03.2011 01:55, schrieb Jonathan M Davis: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis It may be feasible to enhance the single-linked list to support both single- and double linking, via an additional template-parameter "bool doubly" or something like that and some static-ifs in the implementation. I once created a simple single/double-linked queue for D1 like that. Cheers, - Daniel It is always possible to combine types together with 'static if', but the structure and interface is sufficiently different that doubly-linked list should better be a separate type. Is it? It's just a few additional functions and the functions do some additional stuff (mostly handling prev-pointers) for double-linked lists. Much of the single-linked list code can (probably) be reused - so why duplicate code? No, the big difference is you can't move backward in a singly-linked list. So, for instance, SList can only have linearRemove, while (doubly-linked) List can have a constant-time remove. If code duplication is a problem, create a utility function or inherit from a private class. These are implementation details. It should not make them share the same public API.
Re: [GSoC Proposal] Statically Checked Measurement Units
By making the operators on quantity templates:
ref Quantity opAssign(U)( Quantity!(U) u2 ) {
static assert( SameUnit!(U,Unit) );
this.value = u2.value;
return this;
}
Same for addition, subtraction and equality. Multiplication and division
will have to have a different return type.
Seems right to me, am I missing something?
On 30 March 2011 00:39, David Nadlinger wrote:
> On 3/30/11 12:20 AM, Cristi Cobzarenco wrote:
>
>> Well they don't _have_ to be the same type as long they're convertible
>> to one another, and one can make sure they're convertible based on the
>> result of the double-inclusion.
>>
>
> But how would you make them _implicitly_ convertible then?
>
> David
>
--
(Cristi Cobzarenco)
Pofile: http://www.google.com/profiles/cristi.cobzarenco
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On 29/03/2011 16:25, Andrei Alexandrescu wrote: On 03/29/2011 07:46 AM, Steven Schveighoffer wrote: On Tue, 29 Mar 2011 08:04:00 -0400, Bruno Medeiros wrote: On 27/03/2011 19:57, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei Thanks. I hope to do a good job if indeed any IDE related proposals get accepted. BTW, that page lists me are working for Google, but that is incorrect, not sure what gave you that idea (I wish it were true though :P ) I had that impression too. There was a post you made a while back where I thought you suggested quite subtly that you work for them. But I can't find it now (unfortunately my browser doesn't support the "find all messages which made me think Bruno Medeiros works for google" search feature). -Steve It's simply that Bruno and I last met at my Google tech talk. Andrei Eh? No we haven't, not unless I'm sleepwalking into another continent :P We only met at the last ACCU in London. -- Bruno Medeiros - Software Engineer
Re: Review of std.net.isemail part 2
Jonathan M Davis wrote: On 2011-03-30 01:27, Jacob Carlborg wrote: On 3/30/11 1:30 AM, Jesse Phillips wrote: Jacob Carlborg Wrote: I've made a few minor changes: * Renamed EmailStatusCode.Off -> None and On -> Any * Added and clarified the documentation for EmailStatusCode.Any and None * Updated the documentation Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: http://dl.dropbox.com/u/18386187/isemail.html -- /Jacob Carlborg I believe enum values are to be named lowercase first. EmailStatusCode.any I don't know what the style guide says about enum members but if that's the case I'll change the names to begin with lowercase. All names are camelcased. That's not true. ALLCAPS is relatively common in Phobos. There is absolutely no way PI is going to become pi. All type names begin with an uppercase letter, and all variables begin with a lowercase letter (with the possible exception of private member variables beginning with _ - but what's private to a class or struct isn't as critical as the public API regardless). That part is clear. > enum values fall in the same camp as variables. I never heard that before, and it doesn't seem to be true throughout Phobos. Grepping for all enum declarations (there isn't very many of them actually), I found some which were like that, some which start with uppercase, and some which are all caps. I think you're assuming more concensus on style than has ever actually been discussed.
Re: Complete D grammar
I just forked the d-programming-language.org repo on github to fix some grammar errors as a start. I think results should directly go into such a fork so a pull request can be issued later and everything might be merged in at once. Will open a new thread for it.
Re: A case for valueless AA's?
On 03/30/2011 05:02 AM, dsimcha wrote: On 3/29/2011 8:37 PM, Jonathan M Davis wrote: We now have std.container.RedBlackTree, which can be used as a set, but it is a tree rather than a hash table. - Jonathan M Davis This isn't a very good set. It doesn't even support basic set primitives like intersection, difference, union, etc. Furthermore, most programs will probably want a hash set. A tree set is only better when you don't have a good hash function or worst case performance is more important than average case. I'm not saying there's anything wrong with RedBlackTree. It's a perfectly good data structure to implement a set on top of. It's just that it's not a "real" set type because it's not meant to be. Yep, but with balanced binary search trees you get sorting for free ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: Complete D grammar
On 03/30/2011 08:40 AM, Rainer Schuetze wrote: What would be an appropriate way to discuss grammar changes? I think many things should be simplified/clarified. I'd welcome this. I see a few options, but none is currently perfect: - in a wiki. both dsource and wiki4d don't seem to have discussion pages, though. I'm not sure the comparison tables can be converted to something maintainable - it's currently very verbose html. - here on the newsgroup. this would probably have the widest audience, but also might easily get lost. maybe with keeping track of ideas/results in wiki4d. - in bugzilla. this might get spread into multiple entries causing loss of the overview of the overall grammar. I'd vote for wiki + newsgroup. Anyway, if you just put it on a wiki page and announce it here, this would probably launch thread that would feed the page back, hopefully. Denis -- _ vita es estrany spir.wikidot.com
D grammar overhaul
Original discussion forked in the D grammar thread, so I'm opening a new one for this specific issue. The D grammar is in dire need of an overhaul. I suggest we discuss changes here and then put everything into github to issue a pull request once everything's done. I already forked the d-programming-language.org repo to get started by fixing some mistakes. Hereafter I list some issues that come to my mind. Alongside missing things (like @attributes I think) and smaller mistakes parts of it like the whole declarations subgrammar are overly complex and allow strange constructs, partly cause C style arrays and function pointers are still in there even though considered harmful and thus deprecated. (see http://www.digitalmars.com/d/2.0/declaration.html) Furthermore function declarations are obscurely woven into all those productions. So, correct me if I'm wrong but the current grammar even allows monsters like auto ubyte[] ([] bar []) (T)(int i) const if(someCodition) = 2 , foo = 5 ; Also, like Rainer proposed, BasicType2 should be somehow pulled out of Declarator to get rid of the DeclaratorInitializer-DeclaratorIdentifierList-DeclaratorIdentifier construct which CMIIW only exists to disallow multiple types: int a, *b; >> isn't AutoDeclaration already covered by Decl -> StorageClasses Decl and so >> on? Ok it's just an misleading name. It covers not only declarations with 'auto' but all Declarations where no type but only a StorageClass is given: shared a = 5; >> Also there are 3 different instances of mixin: MixinExpression, >> MixinStatement and MixinDeclaration. Even though they all come down to the >> same thing. > I think, the different mixin variants are ok, because you might want to > generate different AST for these. Well I can imagine that MixinStatement is necessary because if you have an ExpStatement with a MixinExpression the result is probably discarded (just like 'a' is discarded in a = 5;). But why do you need another MixinDeclaration? >> Modifiers like shared are repeated, e.g. in BasicType, Attribute, >> TypeSpecialization. > Yes the confusion of const/shared/immutable etc in > Attribute,StorageClass,Types,etc causes a lot of headaches.
Re: Review of std.net.isemail part 2
On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote: > Jonathan M Davis wrote: >> On 2011-03-30 01:27, Jacob Carlborg wrote: >>> On 3/30/11 1:30 AM, Jesse Phillips wrote: Jacob Carlborg Wrote: > I've made a few minor changes: > > * Renamed EmailStatusCode.Off -> None and On -> Any * Added and > clarified the documentation for EmailStatusCode.Any and None * > Updated the documentation > > Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: > http://dl.dropbox.com/u/18386187/isemail.html > > -- > /Jacob Carlborg I believe enum values are to be named lowercase first. EmailStatusCode.any >>> I don't know what the style guide says about enum members but if >>> that's the case I'll change the names to begin with lowercase. >> >> All names are camelcased. > > That's not true. ALLCAPS is relatively common in Phobos. There is > absolutely no way PI is going to become pi. > >> All type names begin with an uppercase letter, and all variables begin >> with a lowercase letter (with the possible exception of private member >> variables beginning with _ - but what's private to a class or struct >> isn't as critical as the public API regardless). > > That part is clear. > > > enum values fall in the same camp as variables. > > I never heard that before, and it doesn't seem to be true throughout > Phobos. Grepping for all enum declarations (there isn't very many of > them actually), I found some which were like that, some which start with > uppercase, and some which are all caps. > > I think you're assuming more concensus on style than has ever actually > been discussed. I think Andrei introduced the camelCase enum convention with his Phobos overhaul back in 2.029. All new modules, and most modules which have seen major changes since then, follow it -- at least in the public API. Examples include std.algorithm, std.datetime, std.file, std.getopt, std.range and std.stdio. I wouldn't mind if PI became pi -- I'd never dream of naming a variable pi anyway, unless it's actually supposed to represent π. Renaming E to e, on the other hand, that's a lot worse. -Lars
Re: A case for valueless AA's?
On Tue, 29 Mar 2011 23:02:35 -0400, dsimcha wrote: On 3/29/2011 8:37 PM, Jonathan M Davis wrote: We now have std.container.RedBlackTree, which can be used as a set, but it is a tree rather than a hash table. - Jonathan M Davis This isn't a very good set. It doesn't even support basic set primitives like intersection, difference, union, etc. std.container.RedBlackTree supports the standard methods, and not much else. I am not the architect for std.container, so I did not want to add methods that might some day be superseded by further additions to the std.container regime. dcollections does support these primitives, so the code already exists, I just am not sure of the interface Andrei wants. Furthermore, most programs will probably want a hash set. A tree set is only better when you don't have a good hash function or worst case performance is more important than average case. A tree-based set's advantage over hash-based is that it's ordered. This means things like insertions and deletions do not affect ranges, whereas an insertion in a hash set can cause a rehash. In addition to that, an ordered set provides excellent slicing ability (dcollections supports this). So it depends on your needs. Tree sets are definitely lower performing, I think Hashes win out pretty much there. I'm not saying there's anything wrong with RedBlackTree. It's a perfectly good data structure to implement a set on top of. It's just that it's not a "real" set type because it's not meant to be. I found that the primitives in RedBlackTree suffice to make a set except for intersection, which cannot be done in a generic fashion with high performance. This function exists in dcollections, and can easily be added to std.container.RedBlackTree. -Steve
Re: A case for valueless AA's?
On Tue, 29 Mar 2011 23:11:53 -0400, Andrej Mitrovic wrote: I had a look at dcollections, it seems to have a few different implementations of a set. And it has intersection (not sure about difference or union). It's boost licensed, I wonder if Steve will make a push of his library to Phobos when its done.. set1.difference(set2) => set1.remove(set2) set1.union(set2) => set1.add(set2) So they are there, but they just aren't called union and difference. intersection isn't a very generic function, so it is called intersect. In fact, I had to add a special implementation function to both Hash and RBTree to get it to work correctly. And yes, I will add intersection to std.container when the API for it becomes clear. -Steve
Re: A case for valueless AA's?
On Tue, 29 Mar 2011 18:42:59 -0400, bearophile
wrote:
Piotr Szturmaj:
void[0][string] aa;
aa["key"] = [];
assert("key" in aa);
Nice. I have done a benchmark, and it seems a void[0][int] uses the same
amount of memory as a int[int]. I have not tried a void[0][string].
Each node in the hash has a pointer (for the next node), a hash (size_t)
and the key and value. Given the granularity of allocation (16 bytes),
anything less than 16 bytes will be 16 bytes.
If the above trick works correctly, a void[0][string] should be the same
size as int[int]. (8 bytes for pointer and hash, 8 bytes for string key,
and hopefully 0 bytes for the value).
BTW, you should not use [] in your code, as this calls a runtime array
allocation function. Better to use something else, not sure what though.
Maybe an enum?
-Steve
Re: Review of std.net.isemail part 2
Lars T. Kyllingstad wrote:
On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
Jonathan M Davis wrote:
On 2011-03-30 01:27, Jacob Carlborg wrote:
On 3/30/11 1:30 AM, Jesse Phillips wrote:
Jacob Carlborg Wrote:
I've made a few minor changes:
* Renamed EmailStatusCode.Off -> None and On -> Any * Added and
clarified the documentation for EmailStatusCode.Any and None *
Updated the documentation
Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs:
http://dl.dropbox.com/u/18386187/isemail.html
--
/Jacob Carlborg
I believe enum values are to be named lowercase first.
EmailStatusCode.any
I don't know what the style guide says about enum members but if
that's the case I'll change the names to begin with lowercase.
All names are camelcased.
That's not true. ALLCAPS is relatively common in Phobos. There is
absolutely no way PI is going to become pi.
All type names begin with an uppercase letter, and all variables begin
with a lowercase letter (with the possible exception of private member
variables beginning with _ - but what's private to a class or struct
isn't as critical as the public API regardless).
That part is clear.
> enum values fall in the same camp as variables.
I never heard that before, and it doesn't seem to be true throughout
Phobos. Grepping for all enum declarations (there isn't very many of
them actually), I found some which were like that, some which start with
uppercase, and some which are all caps.
I think you're assuming more concensus on style than has ever actually
been discussed.
I think Andrei introduced the camelCase enum convention with his Phobos
overhaul back in 2.029. All new modules, and most modules which have
seen major changes since then, follow it -- at least in the public API.
Examples include std.algorithm, std.datetime, std.file, std.getopt,
std.range and std.stdio.
I wouldn't mind if PI became pi -- I'd never dream of naming a variable
pi anyway, unless it's actually supposed to represent π. Renaming E to
e, on the other hand, that's a lot worse.
-Lars
Hardly. The only examples I could find were
algorithm: SwapStrategy, SortOutput
range: traverseOptions, SearchPolicy
There are many more which use other conventions, in other modules.
Note that manifest constants (eg, enum int XXX = value;) are completely
different to enumerated types (eg, enum XXX { AAA, BBB, CCC } )
They're using a keyword in common, but they're quite different concepts.
Re: GSoC-2011 project:: Containers
On Wed, 30 Mar 2011 04:55:52 -0400, KennyTM~ wrote: No, the big difference is you can't move backward in a singly-linked list. So, for instance, SList can only have linearRemove, while (doubly-linked) List can have a constant-time remove. I hate to point it out, but any linked list implementation, whether it be single or double-linked, which does not support O(1) removal is 100% useless. Might as well use an array. Andrei, you really need to fix that. -Steve
State of std.container redesign
If I remember correctly, Andrei proposed a redesign of std.container here on digitalmars.D not too long ago, which included switching to final classes for container types. However, I can't quite remember the outcome of the discussion, and there don't seem to be any related changes by now. Is this idea simply pending implementation, or did you change your mind on this, Andrei? David
Re: Review of std.net.isemail part 2
On Wed, 30 Mar 2011 15:04:49 +0200, Don wrote:
> Lars T. Kyllingstad wrote:
>> On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
>>
>>> Jonathan M Davis wrote:
On 2011-03-30 01:27, Jacob Carlborg wrote:
> On 3/30/11 1:30 AM, Jesse Phillips wrote:
>> Jacob Carlborg Wrote:
>>> I've made a few minor changes:
>>>
>>> * Renamed EmailStatusCode.Off -> None and On -> Any * Added and
>>> clarified the documentation for EmailStatusCode.Any and None *
>>> Updated the documentation
>>>
>>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail
>>> Docs: http://dl.dropbox.com/u/18386187/isemail.html
>>>
>>> --
>>> /Jacob Carlborg
>> I believe enum values are to be named lowercase first.
>> EmailStatusCode.any
> I don't know what the style guide says about enum members but if
> that's the case I'll change the names to begin with lowercase.
All names are camelcased.
>>> That's not true. ALLCAPS is relatively common in Phobos. There is
>>> absolutely no way PI is going to become pi.
>>>
All type names begin with an uppercase letter, and all variables
begin with a lowercase letter (with the possible exception of private
member variables beginning with _ - but what's private to a class or
struct isn't as critical as the public API regardless).
>>> That part is clear.
>>>
>>> > enum values fall in the same camp as variables.
>>>
>>> I never heard that before, and it doesn't seem to be true throughout
>>> Phobos. Grepping for all enum declarations (there isn't very many of
>>> them actually), I found some which were like that, some which start
>>> with uppercase, and some which are all caps.
>>>
>>> I think you're assuming more concensus on style than has ever actually
>>> been discussed.
>>
>>
>> I think Andrei introduced the camelCase enum convention with his Phobos
>> overhaul back in 2.029. All new modules, and most modules which have
>> seen major changes since then, follow it -- at least in the public API.
>> Examples include std.algorithm, std.datetime, std.file, std.getopt,
>> std.range and std.stdio.
>>
>> I wouldn't mind if PI became pi -- I'd never dream of naming a variable
>> pi anyway, unless it's actually supposed to represent π. Renaming E to
>> e, on the other hand, that's a lot worse.
>>
>> -Lars
>
> Hardly. The only examples I could find were algorithm: SwapStrategy,
> SortOutput
> range: traverseOptions, SearchPolicy
> There are many more which use other conventions, in other modules.
I don't intend to start a big debate about this, but I don't think you
looked very hard. All of the modules I mentioned follow the camelCase
convention, and as far as I can tell, none have public enums that follow
other conventions.
std.algorithm: OpenRight, EditOp, SwapStrategy, SortOutput
std.datetime: Month, DayOfWeek, AllowDayOverflow, Direction, PopFirst,
AutoStart
std.file: SpanMode
std.getopt: config (actually not conventional, should be Config, but its
members are still camelCased)
std.range: StoppingPolicy, TransverseOptions, SearchPolicy
std.stdio: KeepTerminator
> Note that manifest constants (eg, enum int XXX = value;) are completely
> different to enumerated types (eg, enum XXX { AAA, BBB, CCC } ) They're
> using a keyword in common, but they're quite different concepts.
I think a sensible rule is that types (and templates that evaluate to
types) start with a capital letter, while values (and functions/templates
that evaluate to values) are camelCased.
-Lars
Re: A case for valueless AA's?
On 3/30/11 5:02 AM, dsimcha wrote: […] Furthermore, most programs will probably want a hash set. First of all, I agree that we really want to have a hash set in Phobos. I think that a first implementation wouldn't even need to support advanced operations like union, intersection, etc., but we should really have some kind of set in the standard library which doesn't look plain ugly (recently, I quickly needed some set implementation and abused AAs for it, but this isn't a serious option). I vaguely remember you having an optimized AA library, David. Does it contain something of interest for a pure set implementation as well, or is it strictly tailored towards hash maps? David
Re: [GSoC Proposal] Statically Checked Measurement Units
On 3/30/11 11:21 AM, Cristi Cobzarenco wrote:
Seems right to me, am I missing something?
opAssign isn't taken into consideration when initializing variables or
passing values to functions. An example probably says more than thousand
words:
---
struct Test {
ref Test opAssign(int i) {
value = i;
return this;
}
int value;
}
void foo(Test t) {}
void main() {
// Neither of the following two lines compiles, IIRC:
Test t = 4; // (1)
foo(4); // (2)
}
---
You can make case (1) work by defining a static opCall taking an int,
which will be called due to property syntax, but I can't think of any
solution for (2).
David
Re: A case for valueless AA's?
== Quote from David Nadlinger (s...@klickverbot.at)'s article > On 3/30/11 5:02 AM, dsimcha wrote: > > […] Furthermore, most programs will probably want a hash set. > First of all, I agree that we really want to have a hash set in Phobos. > I think that a first implementation wouldn't even need to support > advanced operations like union, intersection, etc., but we should really > have some kind of set in the standard library which doesn't look plain > ugly (recently, I quickly needed some set implementation and abused AAs > for it, but this isn't a serious option). I was thinking an easy implementation of sets would be to abuse AAs using the void[0][KeyType] trick under the hood. We could even make a type that wraps any AA conforming to the canonical compile time interface and makes a set, using this trick. > I vaguely remember you having an optimized AA library, David. Does it > contain something of interest for a pure set implementation as well, or > is it strictly tailored towards hash maps? Strictly hash maps (though see above). This is mostly optimized for very large AAs that will be created and destroyed frequently. The optimizations are with regard to memory management. For lookups it's actually slower than the builtin AA b/c it's not as cache efficient.
opSlice() magic for foreach now works?
Hello,
I was trying std.container's SList and noticed foreach iteration works for it,
while it defines neither opApply, nore a (complete) input range interface. But
it does implement a parameter-less opSlice, which maps to "l2 = l1[];". More
precisely, SList (as other container types) defines a 'Range' struct type which
is the return type of opSlice().
TDPL states this method should automagically deal as standard traversal for
foreach (when no opApply or range interface is defined on the collection to be
traverseditself, I guess). But the magic did not work up to very recently.
Does this mean this feature is now implemented? (Note: I tried it for a custom
collection type, and it worked fine.) If yes, I guess it deserves an announce
on the mailing list, as many of thus were waiting for it (hurray!). And a clear
explanation at three places:
* in the 'foreach' section of the language reference manual
* in std.range's doc
* in std.container's doc
Note that this feature fills a long-standing gap in the unification of
collections & ranges: there have been until now 2 contradictory requirements
upon ranges:
1. A collection should be iterable (indeed).
2. A collection should /not/ implement a range interface (be its own range),
instead it should provide
one or more methods returning traversal ranges. This is supposed to be more
flexible.
The only solutions were either to provide opApply in addition to 2., or to
force the user explicitely calling the methods, as in:
foreach (element; myCollection.elements()) {...}
Both are unsatisfying for different reasons. Thank to the "total slice" magic,
opSlice() now implicitely deals as /standard/ traversal for a collection. Like
if it were a kind of 'opTraversal'. This is exactly equivalent, I guess, to
Python's __iter__. opSlice() is thus, if I understand correctly, supposed to
return a 'traversable' thingy, typically an input range.
I have not yet tried to provide a collection implementing opSlice() to funcs
expecting a range. Hope this works as expected, or it will do so soon.
[See also thread about "multiple-item traversal ranges"]
Denis
--
_
vita es estrany
spir.wikidot.com
multiple-item traversal ranges
Hello,
I take the opportunity of opSlice() now seemingly working (see // thread) to
talk about one of the last annoying points for everyday use of ranges for
traversal: the absence of "key-ed traversal", or more generally "multi-item
traversal", as in:
foreach (k,v ; myTable) {...}
After some thought on the topic, I would push for a solution where collection
types which should provide such multi-item traversal methods, would define a
specific struct, eg:
struct Map (K,V) {
struct Pair { K key ; V value; }
struct Range {
@property Pair front () {
assert (! this.empty);
Return Pair(...);
}
...
}
Range opSlice () {
return Range(this);
}
...
}
The advantages of this solution are:
1. It only uses struct: a builtin, simple & efficient feature.
2. It works *now*, as is; it is just a standard to promote.
3. It trivially allows multiple ranges for the same collection type.
4. It is easy to use & understand on the caller side:
foreach (pair ; map) {
doSomethingWith(pair.key, pair.value);
}
foreach (record ; table) {
doSomethingWith(record.name, record.phone, record.mail);
}
Denis
--
_
vita es estrany
spir.wikidot.com
Re: GSoC-2011 project:: Containers
On 03/30/2011 10:41 AM, Daniel Gibson wrote: Am 30.03.2011 10:27, schrieb KennyTM~: On Mar 30, 11 16:18, Daniel Gibson wrote: Am 30.03.2011 01:55, schrieb Jonathan M Davis: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis It may be feasible to enhance the single-linked list to support both single- and double linking, via an additional template-parameter "bool doubly" or something like that and some static-ifs in the implementation. I once created a simple single/double-linked queue for D1 like that. Cheers, - Daniel It is always possible to combine types together with 'static if', but the structure and interface is sufficiently different that doubly-linked list should better be a separate type. Is it? It's just a few additional functions and the functions do some additional stuff (mostly handling prev-pointers) for double-linked lists. Much of the single-linked list code can (probably) be reused - so why duplicate code? The internal mechanisms are different when one has 2-side pointers available (actually simpler, that's why I guess singly-linked lists are rare outside the cons-based functional realm). Denis -- _ vita es estrany spir.wikidot.com
Re: GSoC-2011 project:: Containers
On 03/30/2011 10:55 AM, KennyTM~ wrote: On Mar 30, 11 16:41, Daniel Gibson wrote: Am 30.03.2011 10:27, schrieb KennyTM~: On Mar 30, 11 16:18, Daniel Gibson wrote: Am 30.03.2011 01:55, schrieb Jonathan M Davis: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis It may be feasible to enhance the single-linked list to support both single- and double linking, via an additional template-parameter "bool doubly" or something like that and some static-ifs in the implementation. I once created a simple single/double-linked queue for D1 like that. Cheers, - Daniel It is always possible to combine types together with 'static if', but the structure and interface is sufficiently different that doubly-linked list should better be a separate type. Is it? It's just a few additional functions and the functions do some additional stuff (mostly handling prev-pointers) for double-linked lists. Much of the single-linked list code can (probably) be reused - so why duplicate code? No, the big difference is you can't move backward in a singly-linked list. So, for instance, SList can only have linearRemove, while (doubly-linked) List can have a constant-time remove. If code duplication is a problem, create a utility function or inherit from a private class. These are implementation details. It should not make them share the same public API. I agree. (Esp on not letting implementation details leak out to the public interface). Denis -- _ vita es estrany spir.wikidot.com
Re: Bruno Medeiros has been accepted as a GSoC 2011 mentor for Digital Mars
On 03/30/2011 05:37 AM, Bruno Medeiros wrote: On 29/03/2011 16:25, Andrei Alexandrescu wrote: On 03/29/2011 07:46 AM, Steven Schveighoffer wrote: On Tue, 29 Mar 2011 08:04:00 -0400, Bruno Medeiros wrote: On 27/03/2011 19:57, Andrei Alexandrescu wrote: Bruno Medeiros from Google has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. Please join me in congratulating and wishing the best to Bruno. We have three mentors and two pending applications. We are always looking for mentor and student applications. Please refer to this page for how to apply: http://d-programming-language.org/gsoc2011.html Andrei Thanks. I hope to do a good job if indeed any IDE related proposals get accepted. BTW, that page lists me are working for Google, but that is incorrect, not sure what gave you that idea (I wish it were true though :P ) I had that impression too. There was a post you made a while back where I thought you suggested quite subtly that you work for them. But I can't find it now (unfortunately my browser doesn't support the "find all messages which made me think Bruno Medeiros works for google" search feature). -Steve It's simply that Bruno and I last met at my Google tech talk. Andrei Eh? No we haven't, not unless I'm sleepwalking into another continent :P We only met at the last ACCU in London. Apologies. Apparently, I was the sleepwalking one. Indeed ACCU it was. Andrei
Re: D grammar overhaul
On Mar 30, 11 20:18, Trass3r wrote: Alongside missing things (like @attributes I think) Property: @ Identifier
Re: opSlice() magic for foreach now works?
On Wed, 30 Mar 2011 10:06:26 -0400, spir wrote:
Hello,
I was trying std.container's SList and noticed foreach iteration works
for it, while it defines neither opApply, nore a (complete) input range
interface. But it does implement a parameter-less opSlice, which maps to
"l2 = l1[];". More precisely, SList (as other container types) defines a
'Range' struct type which is the return type of opSlice().
TDPL states this method should automagically deal as standard traversal
for foreach (when no opApply or range interface is defined on the
collection to be traverseditself, I guess). But the magic did not work
up to very recently.
Apparently, it works for SList all the way back to at least 2.050, but I'm
not sure why. It doesn't work for a basic case in 2.052:
struct S
{
struct R
{
@property int front() { return 0;}
void popFront() {}
@property bool empty() const { return true;}
}
R opSlice() { return R();}
}
void main()
{
S s;
foreach(int n; s) {}
}
testopslice.d(19): Error: no property 'opApply' for type 'S'
testopslice.d(19): Error: opApply() function for S must return an int
-Steve
Re: Review of std.net.isemail part 2
On 3/30/11 10:49 AM, Jonathan M Davis wrote: On 2011-03-30 01:27, Jacob Carlborg wrote: On 3/30/11 1:30 AM, Jesse Phillips wrote: Jacob Carlborg Wrote: I've made a few minor changes: * Renamed EmailStatusCode.Off -> None and On -> Any * Added and clarified the documentation for EmailStatusCode.Any and None * Updated the documentation Github: https://github.com/jacob-carlborg/phobos/tree/isemail Docs: http://dl.dropbox.com/u/18386187/isemail.html -- /Jacob Carlborg I believe enum values are to be named lowercase first. EmailStatusCode.any I don't know what the style guide says about enum members but if that's the case I'll change the names to begin with lowercase. All names are camelcased. All type names begin with an uppercase letter, and all variables begin with a lowercase letter (with the possible exception of private member variables beginning with _ - but what's private to a class or struct isn't as critical as the public API regardless). enum values fall in the same camp as variables. We don't really have an actual document anywhere that lays out the style. Andrei has resisted the idea, though I don't think that he's entirely against it, so unfortunately, I don't think that there's currently anywhere that you can look it up. Discussions of the newsgroups have made the decisions on the naming conventions clear though, at least as long as you've paid attention and remember them, which obviously isn't going to happen for newer folks on the list, and unless you're regularly writing Phobos code and making sure that you follow the appropriate conventions, it's probably not all that hard to forget them if they're not what you'd do anyway. In any case, enum values follow the same style as normal variables - camelcased, beginning with a lowercase letter. - Jonathan M Davis Ok, then I'll change to that. -- /Jacob Carlborg
Re: A case for valueless AA's?
On 3/30/11 3:59 PM, dsimcha wrote: == Quote from David Nadlinger (s...@klickverbot.at)'s article On 3/30/11 5:02 AM, dsimcha wrote: […] Furthermore, most programs will probably want a hash set. First of all, I agree that we really want to have a hash set in Phobos. I think that a first implementation wouldn't even need to support advanced operations like union, intersection, etc., but we should really have some kind of set in the standard library which doesn't look plain ugly (recently, I quickly needed some set implementation and abused AAs for it, but this isn't a serious option). I was thinking an easy implementation of sets would be to abuse AAs using the void[0][KeyType] trick under the hood. We could even make a type that wraps any AA conforming to the canonical compile time interface and makes a set, using this trick. Yes, that's what I was thinking about as well, and I really think just using AAs under the hood would be fine for an initial implementation. I'm considering writing up a patch for std.container myself (at least I certainly will if my Thrift project was accepted, because I'd rather target a »canonical« HashSet implementation there), but as I am unsure about what design to use (final classes?), I refrained from it so far. David
Re: opSlice() magic for foreach now works?
On 3/30/11 4:06 PM, spir wrote:
Hello,
I was trying std.container's SList and noticed foreach iteration works
for it, while it defines neither opApply, nore a (complete) input range
interface. But it does implement a parameter-less opSlice, which maps to
"l2 = l1[];". More precisely, SList (as other container types) defines a
'Range' struct type which is the return type of opSlice().
TDPL states this method should automagically deal as standard traversal
for foreach (when no opApply or range interface is defined on the
collection to be traverseditself, I guess). But the magic did not work
up to very recently.
Does this mean this feature is now implemented? (Note: I tried it for a
custom collection type, and it worked fine.) If yes, I guess it deserves
an announce on the mailing list, as many of thus were waiting for it
(hurray!). And a clear explanation at three places:
* in the 'foreach' section of the language reference manual
* in std.range's doc
* in std.container's doc
Note that this feature fills a long-standing gap in the unification of
collections & ranges: there have been until now 2 contradictory
requirements upon ranges:
1. A collection should be iterable (indeed).
2. A collection should /not/ implement a range interface (be its own
range), instead it should provide
one or more methods returning traversal ranges. This is supposed to be
more flexible.
The only solutions were either to provide opApply in addition to 2., or
to force the user explicitely calling the methods, as in:
foreach (element; myCollection.elements()) {...}
Both are unsatisfying for different reasons. Thank to the "total slice"
magic, opSlice() now implicitely deals as /standard/ traversal for a
collection. Like if it were a kind of 'opTraversal'. This is exactly
equivalent, I guess, to Python's __iter__. opSlice() is thus, if I
understand correctly, supposed to return a 'traversable' thingy,
typically an input range.
I have not yet tried to provide a collection implementing opSlice() to
funcs expecting a range. Hope this works as expected, or it will do so
soon.
[See also thread about "multiple-item traversal ranges"]
Denis
Do we have three ways now to implement iteration, opApply, opSlice and
ranges?
--
/Jacob Carlborg
Re: [GSoC Proposal] Statically Checked Measurement Units
Maybe OT, but here's some hackish wizardry you can do with classes:
class Test
{
int value;
this(int x)
{
value = x;
}
}
ref Test foo(Test t ...)
{
return tuple(t)[0];
}
void main()
{
auto result = foo(4);
assert(result.value == 4);
}
The Tuple is used to trick DMD into escaping the local `t` reference.
This won't work with structs. And `t` should be constructed on the
stack, but it seems the destructor gets called only after the exit
from main. The docs do say that construction of classes in variadic
arguments depend on the implementation.
I asked on the newsgroups whether Typesafe Variadic Functions
automatically calling a constructor was a good thing at all. Read
about this feature here under "Typesafe Variadic Functions":
http://www.digitalmars.com/d/2.0/function.html
Re: GSoC-2011 project:: Containers
On Mar 30, 11 21:09, Steven Schveighoffer wrote: On Wed, 30 Mar 2011 04:55:52 -0400, KennyTM~ wrote: No, the big difference is you can't move backward in a singly-linked list. So, for instance, SList can only have linearRemove, while (doubly-linked) List can have a constant-time remove. I hate to point it out, but any linked list implementation, whether it be single or double-linked, which does not support O(1) removal is 100% useless. Might as well use an array. Andrei, you really need to fix that. -Steve You can't O(1) remove an arbitrary range from an SList. O(1) removal is possible only if you also know an iterator right before the range.
Re: opSlice() magic for foreach now works?
On 3/30/11 4:43 PM, Jacob Carlborg wrote: Do we have three ways now to implement iteration, opApply, opSlice and ranges? Wouldn't opSlice only be syntatic sugar for ranges? David
Re: [GSoC Proposal draft] High-Level Networking
On 30/03/11 03.04, Max Klyga wrote: Google Summer of Code 2011 Proposal Draft Abstract The D programming language standard library (Phobos) lacks modules for high-level networking using application layer protocols. This project aims to provide design and implementation of networking modules for the D programming language. Project details Networking abilities are essential for modern programming languages. Currently Phobos contains modules for low-level networking (std.socket), but lacks modules that provide implementation of application level protocols (FTP, HTTP, SMPT, etc.) The goal of this proposal is to design and implement high-level interface for interaction through application level protocols. I plan to implement TELNET-client, TELNET-server, HTTP-client and FTP-client interfaces. This modules will enable D users to easily build applications interacting with web services, applications controlled via TELNET, etc. I will familiarize myself with existing networking libraries in other programming languages to gather information about commonly used techniques and interfaces that got widely adopted. This information will help me with initial design. To ensure ease of use, I will discuss design of modules with D community, seeking for idiomatic D interfaces. I will be using libcurl as a foundation for implementing this modules. This library is portable, supports a wide range of protocols[1]. Using libcurl will provide a quick start. Benefits for D - Greatly simplify creation of network-enabled applications. About me I'm Max Klyga. I am an undergraduate software engineering student at Belarusian State University of Informatics and Radioelectronics (Minsk, Belarus). I'm mainly interested in system programming and after using C++ for some time I found D and fell in love with it. I also have great interest in data-mining and programming language design. I have good C++, C# and Python skills and experience using Qt-framework. I've been successfully using D in my class projects and enjoyed that experience a lot. Lately I've been developing ODBC wrapper for D in my spare time[2]. References 1. http://en.wikipedia.org/wiki/CURL#libcurl 2. https://bitbucket.org/nekuromento/d-odbc Great to see that you're interested in improving the Phobos library! There already is some work being done on this. I've created bindings for libcurl that was accepted into Phobos a couple of days ago (see etc.c.curl module). This is the foundation of some network client classes that I'm doing. I intent to submit this to Phobos when I've implemented the last of the suggestions that I received from the community earlier. My initial target is FTP and HTTP support. See: https://github.com/jcd/phobos/blob/curl/etc/curl.d This does have some overlap with your proposal but that doesn't have to be a bad thing. If this proposal gets accepted you have the libcurl bindings already as a kickstart. Some other options are to extend the client classes that I'm doing. Or to implement the network server classes. /Jonas
Re: [GSoC Proposal] Statically Checked Measurement Units
Yeah, you're right (case (1) also works with a template ctor as well - in
C++ this would allow for implicit conversions as well, that's why I thought
about using it this way). As I said, I had already abandoned this approach
and decided on using .mangleof sorting anyway for elegance. I think my
proposal write-up is almost ready, will submit it today or tomorrow.
(Cristi Cobzarenco)
Pofile: http://www.google.com/profiles/cristi.cobzarenco
On 30 March 2011 15:26, David Nadlinger wrote:
> On 3/30/11 11:21 AM, Cristi Cobzarenco wrote:
>
>> Seems right to me, am I missing something?
>>
>
> opAssign isn't taken into consideration when initializing variables or
> passing values to functions. An example probably says more than thousand
> words:
>
> ---
> struct Test {
> ref Test opAssign(int i) {
>value = i;
>return this;
> }
> int value;
> }
>
> void foo(Test t) {}
>
> void main() {
>// Neither of the following two lines compiles, IIRC:
>Test t = 4; // (1)
>foo(4); // (2)
> }
> ---
>
> You can make case (1) work by defining a static opCall taking an int, which
> will be called due to property syntax, but I can't think of any solution for
> (2).
>
> David
>
Re: multiple-item traversal ranges
Doesn't opApply provide this?
Re: [GSoC Proposal] Statically Checked Measurement Units
Hmmm, the only problem with this is that we would have to require the
library users to do this to their functions. Thanks for the suggestion but
I'll stick with .mangleof sorting.
(Cristi Cobzarenco)
Pofile: http://www.google.com/profiles/cristi.cobzarenco
On 30 March 2011 16:49, Andrej Mitrovic wrote:
> Maybe OT, but here's some hackish wizardry you can do with classes:
>
> class Test
> {
>int value;
>
>this(int x)
>{
>value = x;
>}
> }
>
> ref Test foo(Test t ...)
> {
>return tuple(t)[0];
> }
>
> void main()
> {
>auto result = foo(4);
>assert(result.value == 4);
> }
>
> The Tuple is used to trick DMD into escaping the local `t` reference.
> This won't work with structs. And `t` should be constructed on the
> stack, but it seems the destructor gets called only after the exit
> from main. The docs do say that construction of classes in variadic
> arguments depend on the implementation.
>
> I asked on the newsgroups whether Typesafe Variadic Functions
> automatically calling a constructor was a good thing at all. Read
> about this feature here under "Typesafe Variadic Functions":
> http://www.digitalmars.com/d/2.0/function.html
>
Re: GSoC-2011 project:: Containers
On Wed, 30 Mar 2011 10:45:19 -0400, KennyTM~ wrote: On Mar 30, 11 21:09, Steven Schveighoffer wrote: On Wed, 30 Mar 2011 04:55:52 -0400, KennyTM~ wrote: No, the big difference is you can't move backward in a singly-linked list. So, for instance, SList can only have linearRemove, while (doubly-linked) List can have a constant-time remove. I hate to point it out, but any linked list implementation, whether it be single or double-linked, which does not support O(1) removal is 100% useless. Might as well use an array. Andrei, you really need to fix that. -Steve You can't O(1) remove an arbitrary range from an SList. O(1) removal is possible only if you also know an iterator right before the range. If you have a linked list of any type, and can't do O(1) insertion or removal of a single element, then you have failed. Linked list's complete advantage is arbitrary O(1) insertion and removal. Arrays have O(n) insertion and removal, with random access. Why would I ever use SList in its current form when it has the same complexity as but less features than a builtin array? And yes, you can, if you have a pointer to the element right before the insertion/removal point. This is somewhat ugly, but is the cost of having a singly linked list. I can guarantee anyone who knows what they are doing is never going to use SList, unless they are just interested in a stack type. -Steve
Re: Curl support RFC
On 29/03/11 17.31, Johannes Pfau wrote: Jonas Drewsen wrote: This is a nice protocol parser. I would very much like it to be used with the curl API but without it being a dependency. This is already possible now using the onReceiveHeader callback and this would decouple the two. At least until std.protocol.http is in phobos as well - at that point convenience methods could be added :) /Jonas Thanks, I think I'll propose the parser for the new experimental namespace when it's available. I'm looking forward to that. About the headersReceived callback: You're totally right, it can be done with the onReceiveHeader callback right now. But I think in the common case the user wants the headers in an key/value array. So if the user doesn't want to use the onReceiveHeader api, a headersReceived callback would probably be convenient. But, as said it's not necessary. I'll put it on my todo and reconsider when I get to it :) Reading the curl documentation showed another small trap: CURLOPT_HEADERFUNCTION It's important to note that the callback will be invoked for the headers of all responses received after initiating a request and not just the final response. This includes all responses which occur during authentication negotiation. If you need to operate on only the headers from the final response, you will need to collect headers in the callback yourself and use HTTP status lines, for example, to delimit response boundaries. I think if we store the headers into an array, we should only store the headers of the final response. Another question is should all headers or only final headers trigger the onReceiveHeader callback? Passing only the final headers would require extra work, passing all headers should at least be documented. Yeah... I've discovered this myself as well. The current implementation does as libcurl does it an passes all headers not just for the final subrequest. Thinking of this more, this also means the _receiveHeaderCallback is not 100% correct, as it expects all lines after the first line to be header or empty lines, but it's possible that we get multiple statuslines. It still works, the regex doesn't match anything and the code ignores that line. But this way, the stored statusline will always be the first statusline, which isn't optimal. We'd also need to detect if a line is a statusline to reset the headers array if it's used. Seems like we have to think about this some more. My local version already takes care of this. It was the wrong place for parsing status lines and headers anyway. It is now moved to the Http class where it should have been all the time. I have implemented almost all of the features/changes suggested now. The last one I'm currently fighting is the support for "foreach" and async .byLine/.byChunk. I may have to make some changes in the current design to support this with the calling API that I would like to expose. I wonder who could take the step and open a std.experimental package for submissions? Thank you for the feedback!
Re: GSoC-2011 project:: Containers
On 03/30/2011 03:09 PM, Steven Schveighoffer wrote: On Wed, 30 Mar 2011 04:55:52 -0400, KennyTM~ wrote: No, the big difference is you can't move backward in a singly-linked list. So, for instance, SList can only have linearRemove, while (doubly-linked) List can have a constant-time remove. I hate to point it out, but any linked list implementation, whether it be single or double-linked, which does not support O(1) removal is 100% useless. Might as well use an array. Do you mean removal of an already accessed node/value? If yes, then removal can effectively be O(1), but to first get the access (here, via a pointer) one needs O(n) traversing the list in any case. This, even when the lookup is by index, unlike arrays for which access is O(n) only when looking for a given value. So, for me O(1) removal is half of the story (same reasoning applies to change, insert, slice...). Or do I miss something? As I understand it, link lists are only for "sequential collections" which never change, or only on their front. Thus, I like them for simple lists in the common sense, queue-like collections, or... input/forward ranges ;-). Else, they're close to useless, especiallly in a language like D with it's powerful arrays/slices. Denis -- _ vita es estrany spir.wikidot.com
Re: opSlice() magic for foreach now works?
On 03/30/2011 04:29 PM, Steven Schveighoffer wrote:
On Wed, 30 Mar 2011 10:06:26 -0400, spir wrote:
Hello,
I was trying std.container's SList and noticed foreach iteration works for
it, while it defines neither opApply, nore a (complete) input range
interface. But it does implement a parameter-less opSlice, which maps to "l2
= l1[];". More precisely, SList (as other container types) defines a 'Range'
struct type which is the return type of opSlice().
TDPL states this method should automagically deal as standard traversal for
foreach (when no opApply or range interface is defined on the collection to
be traverseditself, I guess). But the magic did not work up to very recently.
Apparently, it works for SList all the way back to at least 2.050, but I'm not
sure why. It doesn't work for a basic case in 2.052:
struct S
{
struct R
{
@property int front() { return 0;}
void popFront() {}
@property bool empty() const { return true;}
}
R opSlice() { return R();}
}
void main()
{
S s;
foreach(int n; s) {}
}
testopslice.d(19): Error: no property 'opApply' for type 'S'
testopslice.d(19): Error: opApply() function for S must return an int
Strange, I just tried it on a custom, trivial, collection type --precisely to
verify that it does not work only for the standard SList-- and it worked fine
(dmd 2.051 on ubuntu). But now I cannot reproduce this success anymore! get the
same error as you. Will go on trying and tell you if anything changes.
Anyway, if the feature is still unimplemented, why and how does foreach work on
SList. ???
Denis
--
_
vita es estrany
spir.wikidot.com
Re: GSoC-2011 project:: Containers
Am 30.03.2011 16:15, schrieb spir: On 03/30/2011 10:41 AM, Daniel Gibson wrote: Am 30.03.2011 10:27, schrieb KennyTM~: On Mar 30, 11 16:18, Daniel Gibson wrote: Am 30.03.2011 01:55, schrieb Jonathan M Davis: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis It may be feasible to enhance the single-linked list to support both single- and double linking, via an additional template-parameter "bool doubly" or something like that and some static-ifs in the implementation. I once created a simple single/double-linked queue for D1 like that. Cheers, - Daniel It is always possible to combine types together with 'static if', but the structure and interface is sufficiently different that doubly-linked list should better be a separate type. Is it? It's just a few additional functions and the functions do some additional stuff (mostly handling prev-pointers) for double-linked lists. Much of the single-linked list code can (probably) be reused - so why duplicate code? The internal mechanisms are different when one has 2-side pointers available (actually simpler, that's why I guess singly-linked lists are rare outside the cons-based functional realm). Denis Deleting within the list is different, yes, at least if you want to support something else than "delete next element" - in that case you only have to care about the additional pointers. Inserting (at least "insert after this element") is pretty similar, apart from some additional prev-pointers. I mostly thought about the other stuff (insert/remove at front/back) because that were my usecases in my single/double linked queue. Cheers, - Daniel
Re: GSoC-2011 project:: Containers
On Wed, 30 Mar 2011 11:14:20 -0400, spir wrote: On 03/30/2011 03:09 PM, Steven Schveighoffer wrote: On Wed, 30 Mar 2011 04:55:52 -0400, KennyTM~ wrote: No, the big difference is you can't move backward in a singly-linked list. So, for instance, SList can only have linearRemove, while (doubly-linked) List can have a constant-time remove. I hate to point it out, but any linked list implementation, whether it be single or double-linked, which does not support O(1) removal is 100% useless. Might as well use an array. Do you mean removal of an already accessed node/value? If yes, then removal can effectively be O(1), but to first get the access (here, via a pointer) one needs O(n) traversing the list in any case. Of course. With SList, you need O(n) to get to the element, and then O(n) to remove it once you find it ;) This, even when the lookup is by index, unlike arrays for which access is O(n) only when looking for a given value. So, for me O(1) removal is half of the story (same reasoning applies to change, insert, slice...). Or do I miss something? insert also requires O(n) even with a reference to the insertion point in SList. As I understand it, link lists are only for "sequential collections" which never change, or only on their front. Thus, I like them for simple lists in the common sense, queue-like collections, or... input/forward ranges ;-). Else, they're close to useless, especiallly in a language like D with it's powerful arrays/slices. A deque has (amortized) O(1) removal and insertion at the front and end of it, plus has random access. A list's main bonus is O(1) removal and insertion inside the list. And if you do not keep track of the number of elements, it should also have O(1) splicing (inserting another list in the middle of a list, or removing a section of a list defined by two end points). -Steve
Re: GSoC-2011 project:: Containers
On Wed, 30 Mar 2011 11:27:19 -0400, Daniel Gibson wrote: Am 30.03.2011 16:15, schrieb spir: On 03/30/2011 10:41 AM, Daniel Gibson wrote: Am 30.03.2011 10:27, schrieb KennyTM~: On Mar 30, 11 16:18, Daniel Gibson wrote: Am 30.03.2011 01:55, schrieb Jonathan M Davis: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis It may be feasible to enhance the single-linked list to support both single- and double linking, via an additional template-parameter "bool doubly" or something like that and some static-ifs in the implementation. I once created a simple single/double-linked queue for D1 like that. Cheers, - Daniel It is always possible to combine types together with 'static if', but the structure and interface is sufficiently different that doubly-linked list should better be a separate type. Is it? It's just a few additional functions and the functions do some additional stuff (mostly handling prev-pointers) for double-linked lists. Much of the single-linked list code can (probably) be reused - so why duplicate code? The internal mechanisms are different when one has 2-side pointers available (actually simpler, that's why I guess singly-linked lists are rare outside the cons-based functional realm). Denis Deleting within the list is different, yes, at least if you want to support something else than "delete next element" - in that case you only have to care about the additional pointers. Inserting (at least "insert after this element") is pretty similar, apart from some additional prev-pointers. I mostly thought about the other stuff (insert/remove at front/back) because that were my usecases in my single/double linked queue Insert at back for a singly-linked list is O(n). -Steve
Re: opSlice() magic for foreach now works?
On Wed, 30 Mar 2011 11:29:02 -0400, spir wrote: Strange, I just tried it on a custom, trivial, collection type --precisely to verify that it does not work only for the standard SList-- and it worked fine (dmd 2.051 on ubuntu). But now I cannot reproduce this success anymore! get the same error as you. Will go on trying and tell you if anything changes. Anyway, if the feature is still unimplemented, why and how does foreach work on SList. ??? It may be partially/poorly implemented. I looked at the disassembly, and it is indeed calling opSlice and the range primitives inside the foreach loop. There is likely a trigger that the compiler uses to determine if it can do that, and the trigger is probably incorrectly defined. I would think (though I'm not a compiler guy) that to fix this should be minor since the code generation already works in at least one case. Walter? -Steve
Re: GSoC-2011 project:: Containers
Am 30.03.2011 17:31, schrieb Steven Schveighoffer: On Wed, 30 Mar 2011 11:27:19 -0400, Daniel Gibson wrote: Am 30.03.2011 16:15, schrieb spir: On 03/30/2011 10:41 AM, Daniel Gibson wrote: Am 30.03.2011 10:27, schrieb KennyTM~: On Mar 30, 11 16:18, Daniel Gibson wrote: Am 30.03.2011 01:55, schrieb Jonathan M Davis: On 2011-03-29 14:50, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article The fancier stuff would be nice, but we don't even have a doubly-linked list yet. We should get the simpler stuff sorted out before we get particularly fancy, not to mention that it's usually the simple stuff that gets heavily used. For the most part I agree, but a doubly linked list might be **too** simple. Linked lists are so trivial to implement that I'd tend to roll my own that does exactly what I need with regard additional behavior on insertion, etc. rather than wrapping a library solution to get these features. A doubly-linked list is on the list of containers that every standard library should have or it's likely to be considered lacking. I can understand rolling your own for specific uses, but _I_ sure don't want to be doing that if I don't have to. If I want a doubly-linked list, I want to be able to just create a standard one and use it. C++, C#, and Java all have doubly-linked lists in their standard libraries. If no one else ever implements a doubly-linked list for Phobos, I'll probably do it eventually simply because it's one of the containers that is on the short list of containers that pretty much every standard library has. - Jonathan M Davis It may be feasible to enhance the single-linked list to support both single- and double linking, via an additional template-parameter "bool doubly" or something like that and some static-ifs in the implementation. I once created a simple single/double-linked queue for D1 like that. Cheers, - Daniel It is always possible to combine types together with 'static if', but the structure and interface is sufficiently different that doubly-linked list should better be a separate type. Is it? It's just a few additional functions and the functions do some additional stuff (mostly handling prev-pointers) for double-linked lists. Much of the single-linked list code can (probably) be reused - so why duplicate code? The internal mechanisms are different when one has 2-side pointers available (actually simpler, that's why I guess singly-linked lists are rare outside the cons-based functional realm). Denis Deleting within the list is different, yes, at least if you want to support something else than "delete next element" - in that case you only have to care about the additional pointers. Inserting (at least "insert after this element") is pretty similar, apart from some additional prev-pointers. I mostly thought about the other stuff (insert/remove at front/back) because that were my usecases in my single/double linked queue Insert at back for a singly-linked list is O(n). -Steve Not if you keep a pointer to the last element. Then it's just last.next = newElem; last = newElem; or similar. But deleting the last element is O(n) (So I only supported that for the doubly-linked queue). Cheers, - Daniel
Re: GSoC-2011 project:: Containers
On 30 March 2011 10:38, Jonathan M Davis wrote: > On 2011-03-30 01:18, Daniel Gibson wrote: > > Am 30.03.2011 01:55, schrieb Jonathan M Davis: > > > On 2011-03-29 14:50, dsimcha wrote: > > >> == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article > > >> > > >>> The fancier stuff would be nice, but we don't even have a > doubly-linked > > >>> list yet. We should get the simpler stuff sorted out before we get > > >>> particularly fancy, not to mention that it's usually the simple stuff > > >>> that gets heavily used. > > >> > > >> For the most part I agree, but a doubly linked list might be **too** > > >> simple. Linked lists are so trivial to implement that I'd tend to roll > > >> my own that does exactly what I need with regard additional behavior > on > > >> insertion, etc. rather than wrapping a library solution to get these > > >> features. > > > > > > A doubly-linked list is on the list of containers that every standard > > > library should have or it's likely to be considered lacking. I can > > > understand rolling your own for specific uses, but _I_ sure don't want > > > to be doing that if I don't have to. If I want a doubly-linked list, I > > > want to be able to just create a standard one and use it. C++, C#, and > > > Java all have doubly-linked lists in their standard libraries. > > > > > > If no one else ever implements a doubly-linked list for Phobos, I'll > > > probably do it eventually simply because it's one of the containers > that > > > is on the short list of containers that pretty much every standard > > > library has. > > > > > > - Jonathan M Davis > > > > It may be feasible to enhance the single-linked list to support both > > single- and double linking, via an additional template-parameter "bool > > doubly" or something like that and some static-ifs in the implementation. > > I once created a simple single/double-linked queue for D1 like that. > > To what end though? I don't think that that would save you much. While some > of > the implementation would be the same, so much of it would be different, > that > you'd practically have two complete types defined in one template. At that > point, you might as well create a separate class/struct. It's just simpler > to > have them separate, and I don't see any real gain in combining them. Having > both is great, since there are times that you want one and times when you > want > the other, but having both SList and DList (or whatever it would be called) > as > separate types makes sense. > > - Jonathan M Davis > Just a question that popped into my mind, how does D's std.container handle cyclic lists? using static if? -- // Yours sincerely // Emil 'Skeen' Madsen
Article [Submission]: Experiments with template meta-programming in D
http://david.rothlis.net/d/templates/ This misses the "not previously published" rule by a few months, but I don't think anyone apart from me and the googlebot has read it yet. :-) (I mostly wrote it for myself, as a vehicle for experimenting with semantic code highlighting and a style of documentation tied to source control history.) Anyway the article itself is about my fumbling attempts at using templates/mixins/CTFE. It attempts to give a sense of what D is like, rather than being a how-to or in-depth exposition. Cheers, David Röthlisberger.
Re: GSoC-2011 project:: Containers
On Wed, 30 Mar 2011 11:52:15 -0400, Daniel Gibson wrote: Am 30.03.2011 17:31, schrieb Steven Schveighoffer: On Wed, 30 Mar 2011 11:27:19 -0400, Daniel Gibson wrote: Deleting within the list is different, yes, at least if you want to support something else than "delete next element" - in that case you only have to care about the additional pointers. Inserting (at least "insert after this element") is pretty similar, apart from some additional prev-pointers. I mostly thought about the other stuff (insert/remove at front/back) because that were my usecases in my single/double linked queue Insert at back for a singly-linked list is O(n). -Steve Not if you keep a pointer to the last element. Then it's just last.next = newElem; last = newElem; or similar. But deleting the last element is O(n) (So I only supported that for the doubly-linked queue). This is equivalent to keeping a separate insertion point for back-insertion (i.e. can be implemented via insertAfter(node)). But I agree, as long as you don't remove from the end, you can maintain that pointer and abstract the insertBack method. -Steve
Re: Article [Submission]: Experiments with template meta-programming in D
>http://david.rothlis.net/d/templates/ > >This misses the "not previously published" rule by a few months, but I >don't think anyone apart from me and the googlebot has read it yet. :-) >(I mostly wrote it for myself, as a vehicle for experimenting with >semantic code highlighting and a style of documentation tied to source >control history.) > >Anyway the article itself is about my fumbling attempts at using >templates/mixins/CTFE. It attempts to give a sense of what D is like, >rather than being a how-to or in-depth exposition. > >Cheers, > >David Röthlisberger. Wow, that sure looks helpful. Thank you very much :)
Re: [GSoC Proposal draft] High-Level Networking
On 2011-03-30 17:48:59 +0300, Jonas Drewsen said: On 30/03/11 03.04, Max Klyga wrote: snip Great to see that you're interested in improving the Phobos library! There already is some work being done on this. I've created bindings for libcurl that was accepted into Phobos a couple of days ago (see etc.c.curl module). This is the foundation of some network client classes that I'm doing. I intent to submit this to Phobos when I've implemented the last of the suggestions that I received from the community earlier. Could you give links to that suggestions? Is your work on network-clients avaliable online? My initial target is FTP and HTTP support. See: https://github.com/jcd/phobos/blob/curl/etc/curl.d This does have some overlap with your proposal but that doesn't have to be a bad thing. If this proposal gets accepted you have the libcurl bindings already as a kickstart. Some other options are to extend the client classes that I'm doing. Or to implement the network server classes. RFC compilant HTTP-server is very hard to implement, so one solution might be to implement different protocol clients (SMTP, ...) so our work will not overlap. /Jonas
Re: Review of std.net.isemail part 2
On 2011-03-30 04:23, Don wrote: > Jonathan M Davis wrote: > > On 2011-03-30 01:27, Jacob Carlborg wrote: > >> On 3/30/11 1:30 AM, Jesse Phillips wrote: > >>> Jacob Carlborg Wrote: > I've made a few minor changes: > > * Renamed EmailStatusCode.Off -> None and On -> Any > * Added and clarified the documentation for EmailStatusCode.Any and > None * Updated the documentation > > Github: https://github.com/jacob-carlborg/phobos/tree/isemail > Docs: http://dl.dropbox.com/u/18386187/isemail.html > > -- > /Jacob Carlborg > >>> > >>> I believe enum values are to be named lowercase first. > >>> EmailStatusCode.any > >> > >> I don't know what the style guide says about enum members but if that's > >> the case I'll change the names to begin with lowercase. > > > > All names are camelcased. > > That's not true. ALLCAPS is relatively common in Phobos. > There is absolutely no way PI is going to become pi. > > > All type names begin with an uppercase letter, and > > all variables begin with a lowercase letter (with the possible exception > > of private member variables beginning with _ - but what's private to a > > class or struct isn't as critical as the public API regardless). > > That part is clear. > > > enum values fall in the same camp as variables. > > I never heard that before, and it doesn't seem to be true throughout > Phobos. Grepping for all enum declarations (there isn't very many of > them actually), I found some which were like that, some which start with > uppercase, and some which are all caps. > > I think you're assuming more concensus on style than has ever actually > been discussed. I'd have to go digging through the mailing list to find posts on it, but Andrei made it clear that that was what was the intended naming convention and pretty much all of the newer stuff in Phobos follows that convention. Older stuff definitely doesn't follow that convention, but the newer stuff does. In particular, all caps was viewed as bad for enums because of how often they get used in D, and having variables which are all caps used frequently is ugly/annoying. I don't think that there was a huge discussion about it, and I believe that the push for the style I described came primarily from Andrei, but what discussion that there was agreed on treating enum values identically to normal variables as far as their naming coventions go. And all of the newer stuff follows that convention. And since you have to use the enum's name with all of the enum values anyway, it's not like you need a drastic difference in naming to distinguish enums other than manifest constants. - Jonathan M Davis
Re: State of std.container redesign
On 2011-03-30 06:15, David Nadlinger wrote: > If I remember correctly, Andrei proposed a redesign of std.container > here on digitalmars.D not too long ago, which included switching to > final classes for container types. > > However, I can't quite remember the outcome of the discussion, and there > don't seem to be any related changes by now. Is this idea simply pending > implementation, or did you change your mind on this, Andrei? The main thing was that all of the containers would become classes rather than structs which used reference counting. RedBlackTree has already been changed (in git), but the others haven't been yet. - Jonathan M Davis
Re: GSoC-2011 project:: Containers
On 2011-03-30 09:18, Emil Madsen wrote: > On 30 March 2011 10:38, Jonathan M Davis wrote: > > On 2011-03-30 01:18, Daniel Gibson wrote: > > > Am 30.03.2011 01:55, schrieb Jonathan M Davis: > > > > On 2011-03-29 14:50, dsimcha wrote: > > > >> == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article > > > >> > > > >>> The fancier stuff would be nice, but we don't even have a > > > > doubly-linked > > > > > >>> list yet. We should get the simpler stuff sorted out before we get > > > >>> particularly fancy, not to mention that it's usually the simple > > > >>> stuff that gets heavily used. > > > >> > > > >> For the most part I agree, but a doubly linked list might be **too** > > > >> simple. Linked lists are so trivial to implement that I'd tend to > > > >> roll my own that does exactly what I need with regard additional > > > >> behavior > > > > on > > > > > >> insertion, etc. rather than wrapping a library solution to get these > > > >> features. > > > > > > > > A doubly-linked list is on the list of containers that every standard > > > > library should have or it's likely to be considered lacking. I can > > > > understand rolling your own for specific uses, but _I_ sure don't > > > > want to be doing that if I don't have to. If I want a doubly-linked > > > > list, I want to be able to just create a standard one and use it. > > > > C++, C#, and Java all have doubly-linked lists in their standard > > > > libraries. > > > > > > > > If no one else ever implements a doubly-linked list for Phobos, I'll > > > > probably do it eventually simply because it's one of the containers > > > > that > > > > > > is on the short list of containers that pretty much every standard > > > > library has. > > > > > > > > - Jonathan M Davis > > > > > > It may be feasible to enhance the single-linked list to support both > > > single- and double linking, via an additional template-parameter "bool > > > doubly" or something like that and some static-ifs in the > > > implementation. I once created a simple single/double-linked queue for > > > D1 like that. > > > > To what end though? I don't think that that would save you much. While > > some of > > the implementation would be the same, so much of it would be different, > > that > > you'd practically have two complete types defined in one template. At > > that point, you might as well create a separate class/struct. It's just > > simpler to > > have them separate, and I don't see any real gain in combining them. > > Having both is great, since there are times that you want one and times > > when you want > > the other, but having both SList and DList (or whatever it would be > > called) as > > separate types makes sense. > > > > - Jonathan M Davis > > Just a question that popped into my mind, how does D's std.container handle > cyclic lists? using static if? And how would it get a cyclic list? The only linked list of any kind at the moment is SList, which is a singly-linked list. It only has elements in it where you inserted them. There's no way to tell it to insert anything cyclically. Sure, a cyclical list container could be implemented, but none such exists at the moment. std.container is one of the newer modules in Phobos and is still pretty sparse. - Jonathan M Davis
Re: GSoC-2011 project:: Containers
Well, it seems like that different people have lots of different ideas on the way that this project should go. It seems like that double linked list is must for my project. ( Personally my opinion too is that it is better to construct the most used structures rather than trying to code data structures that are rarely used by few people). Just an addition to the things you have been discussing about, how about a Dequeue?
Re: State of std.container redesign
>The main thing was that all of the containers would become classes rather than >structs which used reference counting. RedBlackTree has already been changed >(in git), but the others haven't been yet. Hi, I'm the one who is interested in the GSoC project "Containers". Should the containers that I ( or anyone who gets eligible to do the project ) implement be based on structs or classes?
Re: multiple-item traversal ranges
On 03/30/2011 05:03 PM, Andrej Mitrovic wrote: Doesn't opApply provide this? Yes, but using opApply seems discouraged (scheduled for deprecation?). And opApply doesn't allow playing with other parts of "new style D" (esp algorithms). Denis -- _ vita es estrany spir.wikidot.com
Re: opSlice() magic for foreach now works?
On 03/30/2011 05:34 PM, Steven Schveighoffer wrote: On Wed, 30 Mar 2011 11:29:02 -0400, spir wrote: Strange, I just tried it on a custom, trivial, collection type --precisely to verify that it does not work only for the standard SList-- and it worked fine (dmd 2.051 on ubuntu). But now I cannot reproduce this success anymore! get the same error as you. Will go on trying and tell you if anything changes. Anyway, if the feature is still unimplemented, why and how does foreach work on SList. ??? It may be partially/poorly implemented. I looked at the disassembly, and it is indeed calling opSlice and the range primitives inside the foreach loop. There is likely a trigger that the compiler uses to determine if it can do that, and the trigger is probably incorrectly defined. I would think (though I'm not a compiler guy) that to fix this should be minor since the code generation already works in at least one case. Walter? Yes, i must have hit this trigger button by pure chance on my first attempt (unfortunately, since I was then sure the feature works, i did not keep the code, so i cannot compare). Denis -- _ vita es estrany spir.wikidot.com
Re: multiple-item traversal ranges
On 3/30/11, spir wrote: > On 03/30/2011 05:03 PM, Andrej Mitrovic wrote: >> Doesn't opApply provide this? > > Yes, but using opApply seems discouraged (scheduled for deprecation?). Huh, when did this happen? It's nicely described in TDPL, why would it go away?
Re: [GSoC Proposal draft] High-Level Networking
On 03/30/2011 03:04 AM, Max Klyga wrote: Google Summer of Code 2011 Proposal Draft Abstract The D programming language standard library (Phobos) lacks modules for high-level networking using application layer protocols. This project aims to provide design and implementation of networking modules for the D programming language. Project details Networking abilities are essential for modern programming languages. Currently Phobos contains modules for low-level networking (std.socket), but lacks modules that provide implementation of application level protocols (FTP, HTTP, SMPT, etc.) The goal of this proposal is to design and implement high-level interface for interaction through application level protocols. I plan to implement TELNET-client, TELNET-server, HTTP-client and FTP-client interfaces. This modules will enable D users to easily build applications interacting with web services, applications controlled via TELNET, etc. I will familiarize myself with existing networking libraries in other programming languages to gather information about commonly used techniques and interfaces that got widely adopted. This information will help me with initial design. To ensure ease of use, I will discuss design of modules with D community, seeking for idiomatic D interfaces. I will be using libcurl as a foundation for implementing this modules. This library is portable, supports a wide range of protocols[1]. Using libcurl will provide a quick start. Benefits for D - Greatly simplify creation of network-enabled applications. Good news, I hope this project will be accepted. Anyone to mentor it? Denis -- _ vita es estrany spir.wikidot.com
Re: State of std.container redesign
On Wed, 30 Mar 2011 13:52:29 -0400, Ishan Thilina wrote: The main thing was that all of the containers would become classes rather than structs which used reference counting. RedBlackTree has already been changed (in git), but the others haven't been yet. Hi, I'm the one who is interested in the GSoC project "Containers". Should the containers that I ( or anyone who gets eligible to do the project ) implement be based on structs or classes? Most definitely final classes. I think Andrei has already decided to change the existing ones to classes, and RedBlackTree already is a class in the source tree (not yet in the released version). -Steve
Re: [GSoC Proposal draft] High-Level Networking
On 30/03/11 19.19, BlazingWhitester wrote: On 2011-03-30 17:48:59 +0300, Jonas Drewsen said: On 30/03/11 03.04, Max Klyga wrote: snip Great to see that you're interested in improving the Phobos library! There already is some work being done on this. I've created bindings for libcurl that was accepted into Phobos a couple of days ago (see etc.c.curl module). This is the foundation of some network client classes that I'm doing. I intent to submit this to Phobos when I've implemented the last of the suggestions that I received from the community earlier. Could you give links to that suggestions? Look for threads in this newsgroup that I started and that have curl or libcurl in the title. Is your work on network-clients avaliable online? Yes. I haven't pushed my working copy for some time but you can see an older version in the link I provided (see below). My initial target is FTP and HTTP support. See: https://github.com/jcd/phobos/blob/curl/etc/curl.d This does have some overlap with your proposal but that doesn't have to be a bad thing. If this proposal gets accepted you have the libcurl bindings already as a kickstart. Some other options are to extend the client classes that I'm doing. Or to implement the network server classes. RFC compilant HTTP-server is very hard to implement, so one solution might be to implement different protocol clients (SMTP, ...) so our work will not overlap. Actually I believe that a RFC compliant HTTP-server implementation with only mandatory features is not that hard to do. That would provide a good starting point for future improvements. But my initial thoughts on server classes was not HTTP specific though. It was more like a general server network framework. This framework could in turn be used to create a HTTP server if somebody wanted that. /Jonas
Re: multiple-item traversal ranges
On Wed, 30 Mar 2011 14:03:39 -0400, Andrej Mitrovic wrote: On 3/30/11, spir wrote: On 03/30/2011 05:03 PM, Andrej Mitrovic wrote: Doesn't opApply provide this? Yes, but using opApply seems discouraged (scheduled for deprecation?). Huh, when did this happen? It's nicely described in TDPL, why would it go away? It's not going away. It provides mechanisms that are impossible with ranges. And it does not detract from ranges in general -- one can define both opApply and a range interface. opApply is only for foreach, whereas ranges can be used in any number of ways. -Steve
Re: Review of std.net.isemail part 2
Lars T. Kyllingstad wrote:
On Wed, 30 Mar 2011 15:04:49 +0200, Don wrote:
Lars T. Kyllingstad wrote:
On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
Jonathan M Davis wrote:
On 2011-03-30 01:27, Jacob Carlborg wrote:
On 3/30/11 1:30 AM, Jesse Phillips wrote:
Jacob Carlborg Wrote:
I've made a few minor changes:
* Renamed EmailStatusCode.Off -> None and On -> Any * Added and
clarified the documentation for EmailStatusCode.Any and None *
Updated the documentation
Github: https://github.com/jacob-carlborg/phobos/tree/isemail
Docs: http://dl.dropbox.com/u/18386187/isemail.html
--
/Jacob Carlborg
I believe enum values are to be named lowercase first.
EmailStatusCode.any
I don't know what the style guide says about enum members but if
that's the case I'll change the names to begin with lowercase.
All names are camelcased.
That's not true. ALLCAPS is relatively common in Phobos. There is
absolutely no way PI is going to become pi.
All type names begin with an uppercase letter, and all variables
begin with a lowercase letter (with the possible exception of private
member variables beginning with _ - but what's private to a class or
struct isn't as critical as the public API regardless).
That part is clear.
> enum values fall in the same camp as variables.
I never heard that before, and it doesn't seem to be true throughout
Phobos. Grepping for all enum declarations (there isn't very many of
them actually), I found some which were like that, some which start
with uppercase, and some which are all caps.
I think you're assuming more concensus on style than has ever actually
been discussed.
I think Andrei introduced the camelCase enum convention with his Phobos
overhaul back in 2.029. All new modules, and most modules which have
seen major changes since then, follow it -- at least in the public API.
Examples include std.algorithm, std.datetime, std.file, std.getopt,
std.range and std.stdio.
I wouldn't mind if PI became pi -- I'd never dream of naming a variable
pi anyway, unless it's actually supposed to represent π. Renaming E to
e, on the other hand, that's a lot worse.
-Lars
Hardly. The only examples I could find were algorithm: SwapStrategy,
SortOutput
range: traverseOptions, SearchPolicy
There are many more which use other conventions, in other modules.
I don't intend to start a big debate about this, but I don't think you
looked very hard. All of the modules I mentioned follow the camelCase
convention, and as far as I can tell, none have public enums that follow
other conventions.
std.algorithm: OpenRight, EditOp, SwapStrategy, SortOutput
std.datetime: Month, DayOfWeek, AllowDayOverflow, Direction, PopFirst,
AutoStart
std.file: SpanMode
std.getopt: config (actually not conventional, should be Config, but its
members are still camelCased)
std.range: StoppingPolicy, TransverseOptions, SearchPolicy
std.stdio: KeepTerminator
Note that manifest constants (eg, enum int XXX = value;) are completely
different to enumerated types (eg, enum XXX { AAA, BBB, CCC } ) They're
using a keyword in common, but they're quite different concepts.
I think a sensible rule is that types (and templates that evaluate to
types) start with a capital letter, while values (and functions/templates
that evaluate to values) are camelCased.
-Lars
The point is this: we do NOT have a style guide.
We have consensus on a few things. Types start with a capital letter.
Functions are camelCased. Many other things haven't actually been
discussed and agreed to.
Note that simplistic rules are doomed to failure. For example, template
aliases can be either values or types.
Also, any attempt to use precedent is a disaster since Phobos began as a
complete mishmash of styles. In some cases people erroneously believed
there was a convention, and attempted to adhere to it, even though no
such convention existed.
We desperately need a style guide containing all the things which have
actually been agreed to (and equally importantly, nothing which hasn't).
The simplest thing to do would be to fix up the existing one on the
website which nobody follows.
Re: multiple-item traversal ranges
== Quote from spir (denis.s...@gmail.com)'s article > On 03/30/2011 05:03 PM, Andrej Mitrovic wrote: > > Doesn't opApply provide this? > Yes, but using opApply seems discouraged (scheduled for deprecation?). opApply is less composable, and in current implementations, less efficient than ranges. However, it is **_NOT_** going anywhere, since both internal and external iteration have their advantages. opApply and the tradeoff between internal and external iteration are documented in TDPL. An example of this is that iterating over trees is hard to express with ranges, because it requires an explicit stack. With opApply it can be written as recursion. > And > opApply doesn't allow playing with other parts of "new style D" (esp > algorithms). IMHO it should where possible, but a few bugs in opApply prevent me from fixing this. Phobos should recognize "Iterables", or any type that can be iterated with a single-argument foreach. Input ranges are a subtype of iterables. Eventually std.algorithm should treat iterables as a supertype of ranges and things like map and filter should work.
Re: Review of std.net.isemail part 2
Am 30.03.2011 20:15, schrieb Don:
Lars T. Kyllingstad wrote:
On Wed, 30 Mar 2011 15:04:49 +0200, Don wrote:
Lars T. Kyllingstad wrote:
On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
Jonathan M Davis wrote:
On 2011-03-30 01:27, Jacob Carlborg wrote:
On 3/30/11 1:30 AM, Jesse Phillips wrote:
Jacob Carlborg Wrote:
I've made a few minor changes:
* Renamed EmailStatusCode.Off -> None and On -> Any * Added and
clarified the documentation for EmailStatusCode.Any and None *
Updated the documentation
Github: https://github.com/jacob-carlborg/phobos/tree/isemail
Docs: http://dl.dropbox.com/u/18386187/isemail.html
--
/Jacob Carlborg
I believe enum values are to be named lowercase first.
EmailStatusCode.any
I don't know what the style guide says about enum members but if
that's the case I'll change the names to begin with lowercase.
All names are camelcased.
That's not true. ALLCAPS is relatively common in Phobos. There is
absolutely no way PI is going to become pi.
All type names begin with an uppercase letter, and all variables
begin with a lowercase letter (with the possible exception of private
member variables beginning with _ - but what's private to a class or
struct isn't as critical as the public API regardless).
That part is clear.
> enum values fall in the same camp as variables.
I never heard that before, and it doesn't seem to be true throughout
Phobos. Grepping for all enum declarations (there isn't very many of
them actually), I found some which were like that, some which start
with uppercase, and some which are all caps.
I think you're assuming more concensus on style than has ever actually
been discussed.
I think Andrei introduced the camelCase enum convention with his Phobos
overhaul back in 2.029. All new modules, and most modules which have
seen major changes since then, follow it -- at least in the public API.
Examples include std.algorithm, std.datetime, std.file, std.getopt,
std.range and std.stdio.
I wouldn't mind if PI became pi -- I'd never dream of naming a variable
pi anyway, unless it's actually supposed to represent π. Renaming E to
e, on the other hand, that's a lot worse.
-Lars
Hardly. The only examples I could find were algorithm: SwapStrategy,
SortOutput
range: traverseOptions, SearchPolicy
There are many more which use other conventions, in other modules.
I don't intend to start a big debate about this, but I don't think you
looked very hard. All of the modules I mentioned follow the camelCase
convention, and as far as I can tell, none have public enums that
follow other conventions.
std.algorithm: OpenRight, EditOp, SwapStrategy, SortOutput
std.datetime: Month, DayOfWeek, AllowDayOverflow, Direction, PopFirst,
AutoStart
std.file: SpanMode
std.getopt: config (actually not conventional, should be Config, but
its members are still camelCased)
std.range: StoppingPolicy, TransverseOptions, SearchPolicy
std.stdio: KeepTerminator
Note that manifest constants (eg, enum int XXX = value;) are completely
different to enumerated types (eg, enum XXX { AAA, BBB, CCC } ) They're
using a keyword in common, but they're quite different concepts.
I think a sensible rule is that types (and templates that evaluate to
types) start with a capital letter, while values (and
functions/templates that evaluate to values) are camelCased.
-Lars
The point is this: we do NOT have a style guide.
We have consensus on a few things. Types start with a capital letter.
Functions are camelCased. Many other things haven't actually been
discussed and agreed to.
Note that simplistic rules are doomed to failure. For example, template
aliases can be either values or types.
Also, any attempt to use precedent is a disaster since Phobos began as a
complete mishmash of styles. In some cases people erroneously believed
there was a convention, and attempted to adhere to it, even though no
such convention existed.
We desperately need a style guide containing all the things which have
actually been agreed to (and equally importantly, nothing which hasn't).
The simplest thing to do would be to fix up the existing one on the
website which nobody follows.
What about http://digitalmars.com/d/2.0/dstyle.html ?
Re: GSoC-2011 project:: Containers
On 03/30/2011 05:01 PM, Steven Schveighoffer wrote:
On Wed, 30 Mar 2011 10:45:19 -0400, KennyTM~ wrote:
On Mar 30, 11 21:09, Steven Schveighoffer wrote:
On Wed, 30 Mar 2011 04:55:52 -0400, KennyTM~ wrote:
No, the big difference is you can't move backward in a singly-linked
list. So, for instance, SList can only have linearRemove, while
(doubly-linked) List can have a constant-time remove.
I hate to point it out, but any linked list implementation, whether it
be single or double-linked, which does not support O(1) removal is 100%
useless. Might as well use an array.
Andrei, you really need to fix that.
-Steve
You can't O(1) remove an arbitrary range from an SList. O(1) removal is
possible only if you also know an iterator right before the range.
If you have a linked list of any type, and can't do O(1) insertion or removal
of a single element, then you have failed. Linked list's complete advantage is
arbitrary O(1) insertion and removal. Arrays have O(n) insertion and removal,
with random access. Why would I ever use SList in its current form when it has
the same complexity as but less features than a builtin array?
Because it's O(1) insertion/removal at front (not only of elements, also of
sublists).
And yes, you can, if you have a pointer to the element right before the
insertion/removal point.
Sure, but what kind of programming sorcery provides this pointer without O(n)
traversal? (See my other post).
This is somewhat ugly, but is the cost of having a
singly linked list. I can guarantee anyone who knows what they are doing is
never going to use SList, unless they are just interested in a stack type.
Precisely. It's also very well adapted for input/forward ranges, since all
operations happen at front. What do you think? (The kind of ranges that may
hold their contents). Note that the semantics of range iteration is clearly
analogous to list iteration:
while (node) {
element = node.element;
doSomethingWith(element);
node = node.next;
}
while (! r.empty) {
element = f.front;
doSomethingWith(element);
r.popFront();
}
(Only that range vocabulary is imo rather weird:
while (r.hasNext) {
element = r.nextElement;
doSomethingWith(element);
r.moveNext();
}
)
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Article [Submission]: Experiments with template meta-programming in D
On 3/30/2011 2:34 AM, David Röthlisberger wrote: http://david.rothlis.net/d/templates/ This misses the "not previously published" rule by a few months, I'm afraid it does :-( but I don't think anyone apart from me and the googlebot has read it yet. :-) (I mostly wrote it for myself, as a vehicle for experimenting with semantic code highlighting and a style of documentation tied to source control history.) It's still a nice article and deserves a wider audience. Anyone care to do the honors and post a link to the article on Reddit? I hope you'll write a followup article and submit it!
Re: Review of std.net.isemail part 2
On Wed, 30 Mar 2011 20:19:36 +0200, Daniel Gibson wrote: We desperately need a style guide containing all the things which have actually been agreed to (and equally importantly, nothing which hasn't). The simplest thing to do would be to fix up the existing one on the website which nobody follows. What about http://digitalmars.com/d/2.0/dstyle.html ? That document has little to do with actual D code written and included in Phobos or elsewhere. We really need a new guide. -- Simen
Re: GSoC-2011 project:: Containers
On Mar 30, 11 23:01, Steven Schveighoffer wrote:
And yes, you can, if you have a pointer to the element right before the
insertion/removal point.
That what I've said in the previous post. The point is linearRemove's
interface does not take that pointer.
/// Removes a range from the list in linear time.
Range linearRemove(Range r);
Perhaps SList could provide an O(1) .removeAfter method, like:
/// Remove elements in the range [r.front+1 .. $)
Range removeAfter(Range r) {
// add checking yourself.
r._head._next = null;
return Range(null);
}
or an O(1) .removeOneAfter which may be more useful than chopping the
whole tail:
/// Remove one element in at r.front+1
/// and return the range [r.front+2 .. $)
Range removeOneAfter(Range r) {
// add checking yourself.
r._head._next = r._head._next._next;
r.popFront();
return r;
}
Re: GSoC-2011 project:: Containers
On 03/30/2011 05:30 PM, Steven Schveighoffer wrote: Do you mean removal of an already accessed node/value? If yes, then removal can effectively be O(1), but to first get the access (here, via a pointer) one needs O(n) traversing the list in any case. Of course. With SList, you need O(n) to get to the element, and then O(n) to remove it once you find it ;) I guess you refer to the fact that, in a slist, as opposed to doubly linked list, one misses the 'previous' slot needed to insert or remove. Thus, one must re-traverse to reach it. Is it the issue you're evoking? There is a trick to avoid that, wrote it once long ago (since then I have, like you, only used doubly-linked ones). I guess the point is, while traversing to search a given element (by index, value, pattern matching or whatever) to constantly keep track of the previously visited node. Thus, when you get there, you have the needed trio (previous/current/next) available for whatever operation. Denis -- _ vita es estrany spir.wikidot.com
Re: State of std.container redesign
On 2011-03-30 10:52, Ishan Thilina wrote: > >The main thing was that all of the containers would become classes rather > >than structs which used reference counting. RedBlackTree has already been > >changed (in git), but the others haven't been yet. > > Hi, I'm the one who is interested in the GSoC project "Containers". Should > the containers that I ( or anyone who gets eligible to do the project ) > implement be based on structs or classes? They should all be final classes. It was already the design that all container types should have reference semantics, but Andrei tried to implement them initially as structs with reference semantics using ref counting, and that ran into problems, so it was decided to just make them all final classes. That way, inlining is still possible (thanks to final), and they're quite clearly reference types. - Jonathan M Davis
Re: opSlice() magic for foreach now works?
On 2011-03-30 16:47, David Nadlinger wrote: On 3/30/11 4:43 PM, Jacob Carlborg wrote: Do we have three ways now to implement iteration, opApply, opSlice and ranges? Wouldn't opSlice only be syntatic sugar for ranges? David I have no idea, that's why I'm asking. -- /Jacob Carlborg
Re: multiple-item traversal ranges
On 03/30/2011 08:03 PM, Andrej Mitrovic wrote: On 3/30/11, spir wrote: On 03/30/2011 05:03 PM, Andrej Mitrovic wrote: Doesn't opApply provide this? Yes, but using opApply seems discouraged (scheduled for deprecation?). Huh, when did this happen? It's nicely described in TDPL, why would it go away? Has been mentionned several times on D lists. Dunno why, though... Anyway, D should chose. Beeing forced to implement both opApply and ranges is... well... There is also the apparently half implemented trick of "naked" opSlice() that should provide for magic iteration. Too much is too much. Deniq -- _ vita es estrany spir.wikidot.com
Re: multiple-item traversal ranges
On 03/30/2011 08:22 PM, dsimcha wrote: And opApply doesn't allow playing with other parts of "new style D" (esp algorithms). IMHO it should where possible, but a few bugs in opApply prevent me from fixing this. Phobos should recognize "Iterables", or any type that can be iterated with a single-argument foreach. Input ranges are a subtype of iterables. Eventually std.algorithm should treat iterables as a supertype of ranges and things like map and filter should work. Exactly, and the opSlice() trick recently evoked in a // thread, when works, provides for a first aspect of unification of collections & ranges. Remains to define a kind of super-super-type (iterable) for algorithms. Replace everywhere the isInputRange constraint by isIterable. denis -- _ vita es estrany spir.wikidot.com
Re: Review of std.net.isemail part 2
On 2011-03-30 20:15, Don wrote:
Lars T. Kyllingstad wrote:
On Wed, 30 Mar 2011 15:04:49 +0200, Don wrote:
Lars T. Kyllingstad wrote:
On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
Jonathan M Davis wrote:
On 2011-03-30 01:27, Jacob Carlborg wrote:
On 3/30/11 1:30 AM, Jesse Phillips wrote:
Jacob Carlborg Wrote:
I've made a few minor changes:
* Renamed EmailStatusCode.Off -> None and On -> Any * Added and
clarified the documentation for EmailStatusCode.Any and None *
Updated the documentation
Github: https://github.com/jacob-carlborg/phobos/tree/isemail
Docs: http://dl.dropbox.com/u/18386187/isemail.html
--
/Jacob Carlborg
I believe enum values are to be named lowercase first.
EmailStatusCode.any
I don't know what the style guide says about enum members but if
that's the case I'll change the names to begin with lowercase.
All names are camelcased.
That's not true. ALLCAPS is relatively common in Phobos. There is
absolutely no way PI is going to become pi.
All type names begin with an uppercase letter, and all variables
begin with a lowercase letter (with the possible exception of private
member variables beginning with _ - but what's private to a class or
struct isn't as critical as the public API regardless).
That part is clear.
> enum values fall in the same camp as variables.
I never heard that before, and it doesn't seem to be true throughout
Phobos. Grepping for all enum declarations (there isn't very many of
them actually), I found some which were like that, some which start
with uppercase, and some which are all caps.
I think you're assuming more concensus on style than has ever actually
been discussed.
I think Andrei introduced the camelCase enum convention with his Phobos
overhaul back in 2.029. All new modules, and most modules which have
seen major changes since then, follow it -- at least in the public API.
Examples include std.algorithm, std.datetime, std.file, std.getopt,
std.range and std.stdio.
I wouldn't mind if PI became pi -- I'd never dream of naming a variable
pi anyway, unless it's actually supposed to represent π. Renaming E to
e, on the other hand, that's a lot worse.
-Lars
Hardly. The only examples I could find were algorithm: SwapStrategy,
SortOutput
range: traverseOptions, SearchPolicy
There are many more which use other conventions, in other modules.
I don't intend to start a big debate about this, but I don't think you
looked very hard. All of the modules I mentioned follow the camelCase
convention, and as far as I can tell, none have public enums that
follow other conventions.
std.algorithm: OpenRight, EditOp, SwapStrategy, SortOutput
std.datetime: Month, DayOfWeek, AllowDayOverflow, Direction, PopFirst,
AutoStart
std.file: SpanMode
std.getopt: config (actually not conventional, should be Config, but
its members are still camelCased)
std.range: StoppingPolicy, TransverseOptions, SearchPolicy
std.stdio: KeepTerminator
Note that manifest constants (eg, enum int XXX = value;) are completely
different to enumerated types (eg, enum XXX { AAA, BBB, CCC } ) They're
using a keyword in common, but they're quite different concepts.
I think a sensible rule is that types (and templates that evaluate to
types) start with a capital letter, while values (and
functions/templates that evaluate to values) are camelCased.
-Lars
The point is this: we do NOT have a style guide.
We have consensus on a few things. Types start with a capital letter.
Functions are camelCased. Many other things haven't actually been
discussed and agreed to.
Note that simplistic rules are doomed to failure. For example, template
aliases can be either values or types.
Also, any attempt to use precedent is a disaster since Phobos began as a
complete mishmash of styles. In some cases people erroneously believed
there was a convention, and attempted to adhere to it, even though no
such convention existed.
We desperately need a style guide containing all the things which have
actually been agreed to (and equally importantly, nothing which hasn't).
The simplest thing to do would be to fix up the existing one on the
website which nobody follows.
So, should I change the enum members to start with lowercase or leave it
like it is?
--
/Jacob Carlborg
Re: GSoC-2011 project:: Containers
On Wed, 30 Mar 2011 14:21:35 -0400, spir wrote: On 03/30/2011 05:01 PM, Steven Schveighoffer wrote: On Wed, 30 Mar 2011 10:45:19 -0400, KennyTM~ wrote: On Mar 30, 11 21:09, Steven Schveighoffer wrote: On Wed, 30 Mar 2011 04:55:52 -0400, KennyTM~ wrote: No, the big difference is you can't move backward in a singly-linked list. So, for instance, SList can only have linearRemove, while (doubly-linked) List can have a constant-time remove. I hate to point it out, but any linked list implementation, whether it be single or double-linked, which does not support O(1) removal is 100% useless. Might as well use an array. Andrei, you really need to fix that. -Steve You can't O(1) remove an arbitrary range from an SList. O(1) removal is possible only if you also know an iterator right before the range. If you have a linked list of any type, and can't do O(1) insertion or removal of a single element, then you have failed. Linked list's complete advantage is arbitrary O(1) insertion and removal. Arrays have O(n) insertion and removal, with random access. Why would I ever use SList in its current form when it has the same complexity as but less features than a builtin array? Because it's O(1) insertion/removal at front (not only of elements, also of sublists). I have O(1) insertion/removal at the end of an array. Just call the end the "front" and you have the same thing. BTW, deque supports O(1) insertion and removal at both ends. And yes, you can, if you have a pointer to the element right before the insertion/removal point. Sure, but what kind of programming sorcery provides this pointer without O(n) traversal? (See my other post). You are not getting it. SList's implementation to remove the element containing 5: auto r = find(mySList[], 5); // O(n) operation mySList.linearRemove(take(r, 1)); // O(n) operation, even though I just searched for the element. Expected implementation: auto r = find(mySList[], 5); // O(n) operation mySList.remove(take(r, 1)); // O(1) operation If the second operation is O(n), *EVEN THOUGH YOU JUST GOT A POINTER TO IT*, then the list is a failure. An SList range should retain enough info to be able to remove its front element, it's not that hard. From en.wikipedia.org: "The principal benefit of a linked list over a conventional array is that the list elements can easily be added or removed without reallocation or reorganization of the entire structure because the data items need not be stored contiguously in memory or on disk. Linked lists allow insertion and removal of nodes at any point in the list, and can do so with a constant number of operations if the link previous to the link being added or removed is maintained during list traversal." -Steve
Re: GSoC-2011 project:: Containers
On Wed, 30 Mar 2011 14:30:37 -0400, spir wrote: On 03/30/2011 05:30 PM, Steven Schveighoffer wrote: Do you mean removal of an already accessed node/value? If yes, then removal can effectively be O(1), but to first get the access (here, via a pointer) one needs O(n) traversing the list in any case. Of course. With SList, you need O(n) to get to the element, and then O(n) to remove it once you find it ;) I guess you refer to the fact that, in a slist, as opposed to doubly linked list, one misses the 'previous' slot needed to insert or remove. Thus, one must re-traverse to reach it. Is it the issue you're evoking? There is a trick to avoid that, wrote it once long ago (since then I have, like you, only used doubly-linked ones). I guess the point is, while traversing to search a given element (by index, value, pattern matching or whatever) to constantly keep track of the previously visited node. Thus, when you get there, you have the needed trio (previous/current/next) available for whatever operation. Yes, the range should do this. -Steve
Re: GSoC-2011 project:: Containers
On Wed, 30 Mar 2011 14:28:49 -0400, KennyTM~ wrote:
On Mar 30, 11 23:01, Steven Schveighoffer wrote:
And yes, you can, if you have a pointer to the element right before the
insertion/removal point.
That what I've said in the previous post. The point is linearRemove's
interface does not take that pointer.
/// Removes a range from the list in linear time.
Range linearRemove(Range r);
Perhaps SList could provide an O(1) .removeAfter method, like:
/// Remove elements in the range [r.front+1 .. $)
Range removeAfter(Range r) {
// add checking yourself.
r._head._next = null;
return Range(null);
}
or an O(1) .removeOneAfter which may be more useful than chopping the
whole tail:
/// Remove one element in at r.front+1
/// and return the range [r.front+2 .. $)
Range removeOneAfter(Range r) {
// add checking yourself.
r._head._next = r._head._next._next;
r.popFront();
return r;
}
So I have an SList!int, and I want to remove a certain element in linear
time. How can I do this with SList, even with your primitives? Answer:
the really convoluted difficult way:
void removeSpecificElement(SList!int mylist, int elem)
{
if(!mylist.empty && mylist.front() == elem)
mylist.removeFront();
else
{
auto r1 = slist[];
auto r2 = r1;
r1.popFront();
while(!r1.empty && r1.front != elem)
{
r2 = r1;
r1.popFront();
}
if(!r1.empty)
mylist.removeOneAfter(r2);
}
}
Whereas, I'd rather have:
mylist.remove(take(find(mylist, elem), 1));
BTW, I realized while reading the docs that this only applies to removal,
insertion does have an insertAfter function (though with the range
properly implemented, insert becomes possible).
-Steve
Re: GSoC-2011 project:: Containers
On Mar 31, 11 02:30, spir wrote: On 03/30/2011 05:30 PM, Steven Schveighoffer wrote: Do you mean removal of an already accessed node/value? If yes, then removal can effectively be O(1), but to first get the access (here, via a pointer) one needs O(n) traversing the list in any case. Of course. With SList, you need O(n) to get to the element, and then O(n) to remove it once you find it ;) I guess you refer to the fact that, in a slist, as opposed to doubly linked list, one misses the 'previous' slot needed to insert or remove. Thus, one must re-traverse to reach it. Is it the issue you're evoking? There is a trick to avoid that, wrote it once long ago (since then I have, like you, only used doubly-linked ones). I guess the point is, while traversing to search a given element (by index, value, pattern matching or whatever) to constantly keep track of the previously visited node. Thus, when you get there, you have the needed trio (previous/current/next) available for whatever operation. Denis Using 'previous' pointer to allow O(1) removal will make this program crash, although I don't know if this is allowed or not: auto r = slist.front; r.popFront(); slist.removeFront(); slist.remove(r); (You don't need 'next' because it is already stored in the 'current' node.)
Re: Complete D grammar
On 3/29/2011 2:48 PM, Rainer Schuetze wrote: Could you please add a bugzilla entry for your wiki notes? I hope you mean an entry with a link to the wiki. The comparison itself might a bit too large itself for bugzilla (html is larger than 800kB) ;-) A link is fine.
__traits so long and ugly, what about ::?
I think :: is not used in the language.
In a recent article about D I saw:
mixin(__traits(identifier, T) ~ " " ~
to!string(tolower(__traits(identifier, T)[0])) ~
__traits(identifier, T)[1..$] ~ ";");
What if foo::bar were an alias for __traits(foo, bar) ?
The code would look like this:
mixin(T::identifier ~ " " ~
to!string(tolower(T::identifier[0])) ~
T::identifier[1..$] ~ ";");
What do you think?
Another uses:
__traits(int, isArithmetic) ==> int::isArithmetic
__traits(C, isAbstractClass) ==> C::isAbstractClass
__traits(hasMember, S, "m") ==> S::hasMember("m")
Well, you get the idea...
:: might be applied to other compile time uses, but I just came up with
this...
Re: __traits so long and ugly, what about ::?
You are not the only one to find __traits ugly – although not directly related to your question, it has been proposed several times to ditch is(typeof()) and __traits and replace them with a magic »meta« namespace. There is even a bug report about it: http://d.puremagic.com/issues/show_bug.cgi?id=3702 David
Re: State of std.container redesign
On 3/30/11 1:07 PM, Steven Schveighoffer wrote: On Wed, 30 Mar 2011 13:52:29 -0400, Ishan Thilina wrote: The main thing was that all of the containers would become classes rather than structs which used reference counting. RedBlackTree has already been changed (in git), but the others haven't been yet. Hi, I'm the one who is interested in the GSoC project "Containers". Should the containers that I ( or anyone who gets eligible to do the project ) implement be based on structs or classes? Most definitely final classes. I think Andrei has already decided to change the existing ones to classes, and RedBlackTree already is a class in the source tree (not yet in the released version). -Steve That is correct. We're looking for classes, preponderently final classes. Emphasis is not on hierarchy due to the many possible characteristics of containers, but instead on name conformance. Andrei
Re: Review of std.net.isemail part 2
On 2011-03-30 11:47, Jacob Carlborg wrote:
> On 2011-03-30 20:15, Don wrote:
> > Lars T. Kyllingstad wrote:
> >> On Wed, 30 Mar 2011 15:04:49 +0200, Don wrote:
> >>> Lars T. Kyllingstad wrote:
> On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
> > Jonathan M Davis wrote:
> >> On 2011-03-30 01:27, Jacob Carlborg wrote:
> >>> On 3/30/11 1:30 AM, Jesse Phillips wrote:
> Jacob Carlborg Wrote:
> > I've made a few minor changes:
> >
> > * Renamed EmailStatusCode.Off -> None and On -> Any * Added and
> > clarified the documentation for EmailStatusCode.Any and None *
> > Updated the documentation
> >
> > Github: https://github.com/jacob-carlborg/phobos/tree/isemail
> > Docs: http://dl.dropbox.com/u/18386187/isemail.html
> >
> > --
> > /Jacob Carlborg
>
> I believe enum values are to be named lowercase first.
> EmailStatusCode.any
> >>>
> >>> I don't know what the style guide says about enum members but if
> >>> that's the case I'll change the names to begin with lowercase.
> >>
> >> All names are camelcased.
> >
> > That's not true. ALLCAPS is relatively common in Phobos. There is
> > absolutely no way PI is going to become pi.
> >
> >> All type names begin with an uppercase letter, and all variables
> >> begin with a lowercase letter (with the possible exception of
> >> private member variables beginning with _ - but what's private to a
> >> class or struct isn't as critical as the public API regardless).
> >
> > That part is clear.
> >
> > > enum values fall in the same camp as variables.
> >
> > I never heard that before, and it doesn't seem to be true throughout
> > Phobos. Grepping for all enum declarations (there isn't very many of
> > them actually), I found some which were like that, some which start
> > with uppercase, and some which are all caps.
> >
> > I think you're assuming more concensus on style than has ever
> > actually been discussed.
>
> I think Andrei introduced the camelCase enum convention with his
> Phobos overhaul back in 2.029. All new modules, and most modules
> which have seen major changes since then, follow it -- at least in
> the public API. Examples include std.algorithm, std.datetime,
> std.file, std.getopt, std.range and std.stdio.
>
> I wouldn't mind if PI became pi -- I'd never dream of naming a
> variable pi anyway, unless it's actually supposed to represent π.
> Renaming E to e, on the other hand, that's a lot worse.
>
> -Lars
> >>>
> >>> Hardly. The only examples I could find were algorithm: SwapStrategy,
> >>> SortOutput
> >>> range: traverseOptions, SearchPolicy
> >>> There are many more which use other conventions, in other modules.
> >>
> >> I don't intend to start a big debate about this, but I don't think you
> >> looked very hard. All of the modules I mentioned follow the camelCase
> >> convention, and as far as I can tell, none have public enums that
> >> follow other conventions.
> >>
> >> std.algorithm: OpenRight, EditOp, SwapStrategy, SortOutput
> >>
> >> std.datetime: Month, DayOfWeek, AllowDayOverflow, Direction, PopFirst,
> >> AutoStart
> >> std.file: SpanMode
> >>
> >> std.getopt: config (actually not conventional, should be Config, but
> >> its members are still camelCased)
> >>
> >> std.range: StoppingPolicy, TransverseOptions, SearchPolicy
> >>
> >> std.stdio: KeepTerminator
> >>
> >>> Note that manifest constants (eg, enum int XXX = value;) are completely
> >>> different to enumerated types (eg, enum XXX { AAA, BBB, CCC } ) They're
> >>> using a keyword in common, but they're quite different concepts.
> >>
> >> I think a sensible rule is that types (and templates that evaluate to
> >> types) start with a capital letter, while values (and
> >> functions/templates that evaluate to values) are camelCased.
> >>
> >> -Lars
> >
> > The point is this: we do NOT have a style guide.
> > We have consensus on a few things. Types start with a capital letter.
> > Functions are camelCased. Many other things haven't actually been
> > discussed and agreed to.
> >
> > Note that simplistic rules are doomed to failure. For example, template
> > aliases can be either values or types.
> >
> > Also, any attempt to use precedent is a disaster since Phobos began as a
> > complete mishmash of styles. In some cases people erroneously believed
> > there was a convention, and attempted to adhere to it, even though no
> > such convention existed.
> >
> > We desperately need a style guide containing all the things which have
> > actually been agreed to (and equally importantly, nothing which hasn't).
> > The simplest thing to do would be to fix up the existing one on the
> > website which nobody follows.
>
> So, should I change the enum members to start with lower
Re: __traits so long and ugly, what about ::?
On 3/30/11 4:32 PM, David Nadlinger wrote: You are not the only one to find __traits ugly – although not directly related to your question, it has been proposed several times to ditch is(typeof()) and __traits and replace them with a magic »meta« namespace. There is even a bug report about it: http://d.puremagic.com/issues/show_bug.cgi?id=3702 David David, thanks for the answer. I am aware of that proposal, but I don't like it because it's not very readble. You have to read "meta isArithmetic int", kind of like how yoda speaks, but in the other case, "int::isArithmetic" is much more natural and shorter and nicer. I'm just suggesting a syntax for accessing compile-time things. It seems :: is unused...
Re: Review of std.net.isemail part 2
On 3/30/11 1:47 PM, Jacob Carlborg wrote: So, should I change the enum members to start with lowercase or leave it like it is? Change please. Thanks, Andrei
Re: Review of std.net.isemail part 2
On 2011-03-30 11:15, Don wrote:
> Lars T. Kyllingstad wrote:
> > On Wed, 30 Mar 2011 15:04:49 +0200, Don wrote:
> >> Lars T. Kyllingstad wrote:
> >>> On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
> Jonathan M Davis wrote:
> > On 2011-03-30 01:27, Jacob Carlborg wrote:
> >> On 3/30/11 1:30 AM, Jesse Phillips wrote:
> >>> Jacob Carlborg Wrote:
> I've made a few minor changes:
>
> * Renamed EmailStatusCode.Off -> None and On -> Any * Added and
> clarified the documentation for EmailStatusCode.Any and None *
> Updated the documentation
>
> Github: https://github.com/jacob-carlborg/phobos/tree/isemail
> Docs: http://dl.dropbox.com/u/18386187/isemail.html
>
> --
> /Jacob Carlborg
> >>>
> >>> I believe enum values are to be named lowercase first.
> >>> EmailStatusCode.any
> >>
> >> I don't know what the style guide says about enum members but if
> >> that's the case I'll change the names to begin with lowercase.
> >
> > All names are camelcased.
>
> That's not true. ALLCAPS is relatively common in Phobos. There is
> absolutely no way PI is going to become pi.
>
> > All type names begin with an uppercase letter, and all variables
> > begin with a lowercase letter (with the possible exception of private
> > member variables beginning with _ - but what's private to a class or
> > struct isn't as critical as the public API regardless).
>
> That part is clear.
>
> > enum values fall in the same camp as variables.
>
> I never heard that before, and it doesn't seem to be true throughout
> Phobos. Grepping for all enum declarations (there isn't very many of
> them actually), I found some which were like that, some which start
> with uppercase, and some which are all caps.
>
> I think you're assuming more concensus on style than has ever actually
> been discussed.
> >>>
> >>> I think Andrei introduced the camelCase enum convention with his Phobos
> >>> overhaul back in 2.029. All new modules, and most modules which have
> >>> seen major changes since then, follow it -- at least in the public API.
> >>> Examples include std.algorithm, std.datetime, std.file, std.getopt,
> >>> std.range and std.stdio.
> >>>
> >>> I wouldn't mind if PI became pi -- I'd never dream of naming a variable
> >>> pi anyway, unless it's actually supposed to represent π. Renaming E to
> >>> e, on the other hand, that's a lot worse.
> >>>
> >>> -Lars
> >>
> >> Hardly. The only examples I could find were algorithm: SwapStrategy,
> >> SortOutput
> >> range: traverseOptions, SearchPolicy
> >> There are many more which use other conventions, in other modules.
> >
> > I don't intend to start a big debate about this, but I don't think you
> > looked very hard. All of the modules I mentioned follow the camelCase
> > convention, and as far as I can tell, none have public enums that follow
> > other conventions.
> >
> > std.algorithm: OpenRight, EditOp, SwapStrategy, SortOutput
> >
> > std.datetime: Month, DayOfWeek, AllowDayOverflow, Direction, PopFirst,
> > AutoStart
> > std.file: SpanMode
> >
> > std.getopt: config (actually not conventional, should be Config, but its
> > members are still camelCased)
> >
> > std.range: StoppingPolicy, TransverseOptions, SearchPolicy
> >
> > std.stdio: KeepTerminator
> >
> >> Note that manifest constants (eg, enum int XXX = value;) are completely
> >> different to enumerated types (eg, enum XXX { AAA, BBB, CCC } ) They're
> >> using a keyword in common, but they're quite different concepts.
> >
> > I think a sensible rule is that types (and templates that evaluate to
> > types) start with a capital letter, while values (and functions/templates
> > that evaluate to values) are camelCased.
> >
> > -Lars
>
> The point is this: we do NOT have a style guide.
> We have consensus on a few things. Types start with a capital letter.
> Functions are camelCased. Many other things haven't actually been
> discussed and agreed to.
>
> Note that simplistic rules are doomed to failure. For example, template
> aliases can be either values or types.
>
> Also, any attempt to use precedent is a disaster since Phobos began as a
> complete mishmash of styles. In some cases people erroneously believed
> there was a convention, and attempted to adhere to it, even though no
> such convention existed.
>
> We desperately need a style guide containing all the things which have
> actually been agreed to (and equally importantly, nothing which hasn't).
> The simplest thing to do would be to fix up the existing one on the
> website which nobody follows.
I've tried to get Andrei to agree to a style guide a few times, but he's
generally pushed back on it. I definitely think that we should have one if we
want to actually have a consistent style, but thus far, he hasn't agreed to
Re: __traits so long and ugly, what about ::?
On Mar 31, 11 03:28, Ary Manzana wrote:
I think :: is not used in the language.
In a recent article about D I saw:
mixin(__traits(identifier, T) ~ " " ~
to!string(tolower(__traits(identifier, T)[0])) ~
__traits(identifier, T)[1..$] ~ ";");
What if foo::bar were an alias for __traits(foo, bar) ?
The code would look like this:
mixin(T::identifier ~ " " ~
to!string(tolower(T::identifier[0])) ~
T::identifier[1..$] ~ ";");
What do you think?
Another uses:
__traits(int, isArithmetic) ==> int::isArithmetic
__traits(C, isAbstractClass) ==> C::isAbstractClass
You've got the order wrong.
__traits(hasMember, S, "m") ==> S::hasMember("m")
Well, you get the idea...
:: might be applied to other compile time uses, but I just came up with
this...
-1.
This is confusing as :: is used to separate scopes in C++ (and PHP too).
e.g.
struct A {
int x;
bool isSame(const A other) pure const { return x == other.x; }
}
void main () {
A a = A(2), b = A(2);
assert ( a.isSame(b)); // ok
assert (! a::isSame(b)); // ???
}
(How about that 'meta' namespace proposal? meta.hasMember(S, "m") )
Re: Review of std.net.isemail part 2
On Mar 31, 11 02:22, Simen kjaeraas wrote: On Wed, 30 Mar 2011 20:19:36 +0200, Daniel Gibson wrote: We desperately need a style guide containing all the things which have actually been agreed to (and equally importantly, nothing which hasn't). The simplest thing to do would be to fix up the existing one on the website which nobody follows. What about http://digitalmars.com/d/2.0/dstyle.html ? That document has little to do with actual D code written and included in Phobos or elsewhere. We really need a new guide. Is this still the case? The issue has been brought up several times in this NG and I thought it should have been fixed. Except 'Two blank lines separating function bodies' the new Phobos modules (just looking at container.d) conform to this style guide quite well.
Re: __traits so long and ugly, what about ::?
"Ary Manzana" wrote in message news:in0169$5sb$1...@digitalmars.com... > On 3/30/11 4:32 PM, David Nadlinger wrote: >> You are not the only one to find __traits ugly - although not directly >> related to your question, it has been proposed several times to ditch >> is(typeof()) and __traits and replace them with a magic »meta« >> namespace. There is even a bug report about it: >> http://d.puremagic.com/issues/show_bug.cgi?id=3702 >> >> David > > David, thanks for the answer. I am aware of that proposal, but I don't > like it because it's not very readble. You have to read "meta isArithmetic > int", kind of like how yoda speaks, but in the other case, > "int::isArithmetic" is much more natural and shorter and nicer. > > I'm just suggesting a syntax for accessing compile-time things. It seems > :: is unused... I've always felt the meta namespace should be member-call syntax: int.meta.whatever Your suggestion is a nice shortcut to that, though.
Re: Review of std.net.isemail part 2
On 3/30/11 2:47 PM, Jonathan M Davis wrote: I've tried to get Andrei to agree to a style guide a few times, but he's generally pushed back on it. I definitely think that we should have one if we want to actually have a consistent style, but thus far, he hasn't agreed to have one. I think that's not representing my viewpoint quite accurately, but getting to the bottom of whatever misunderstanding was there is not important. It would be helpful to have a broad style guide. The existing one is a good start and is in fact already observed by much of Phobos (and in particular by most of my code). The problem with writing a more elaborate guide is finding the person(s) with the time and inclination to write a draft, get it vetted by the major contributors, and take it to completion. For my money, just take the first that applies: - Is it a function name? Use thisStyle. - Is it a value (be it constant or variable)? Use thisStyle. - Is it a type? Use ThisStyle. - Is it a module name? Use this_style. Beyond naming: - Define variables as late as possible. - Define constants and other names scoped appropriately. - Prefer anonymous temporaries to named values within reason. - Prefer ? : to if/else within reason. - Prefer compact, effective code to verbose code within reason. Make every line count. Nitpicks that 9 people have 10 opinions of: - No 2+ empty lines please. Within a function, an empty line at best should be replaced by a comment describing the meaning of the next block. - Try to fit functions loosely on one editor page. - Brace on its own line. (In fact I don't care much either way, but this is the way the majority of the code is.) Note that this does cost more vertical space so it somewhat clashes with the previous point. - Please avoid > 80 columns unless you feel it induces sterility in the long term. - No tabs please. - Comments should be high level (describing 3-10 lines) instead of low-level (describing the mechanics of the next line, which are already obvious in code). Thanks, Andrei
Re: __traits so long and ugly, what about ::?
On 30/03/2011 20:28, Ary Manzana wrote:
I think :: is not used in the language.
In a recent article about D I saw:
mixin(__traits(identifier, T) ~ " " ~
to!string(tolower(__traits(identifier, T)[0])) ~
__traits(identifier, T)[1..$] ~ ";");
What if foo::bar were an alias for __traits(foo, bar) ?
The code would look like this:
mixin(T::identifier ~ " " ~
to!string(tolower(T::identifier[0])) ~
T::identifier[1..$] ~ ";");
What do you think?
Another uses:
__traits(int, isArithmetic) ==> int::isArithmetic
__traits(C, isAbstractClass) ==> C::isAbstractClass
__traits(hasMember, S, "m") ==> S::hasMember("m")
Well, you get the idea...
:: might be applied to other compile time uses, but I just came up with
this...
Hmn, interesting idea! I noticed, however, that the "foo" and "bar" in
your example are actually swapped...
__traits(foo, bar) ==> foo::bar
should be
__traits(foo, bar) ==> bar::foo
For many the uses of __traits I can recall off the top of my head, it
certainly seems to be both elegant and intuitive. One sore thumb would
be __traits(compiles, ...) which I believe gets used quite frequently in
Phobos.
Clarifications and my lack of insight into the complete breadth of
__traits's capabilities and variations aside, I think this is the best
suggestion for the replacement of the much maligned experimental keyword
that I have seen posted since Don's suggestion of a magic namespace[1].
I'm not 100% sure if this :: syntax could also tidy up is() expressions
too, but if it can, I can imagine it having a lot of support. If
language design was a democracy, I'd certainly vote for it ^^
A...
[1] Search the NG for "Proposal: Replace __traits and is(typeof(XXX))
with a 'magic namespace'."
Re: __traits so long and ugly, what about ::?
On 30/03/2011 21:09, Alix Pexton wrote:
On 30/03/2011 20:28, Ary Manzana wrote:
I think :: is not used in the language.
In a recent article about D I saw:
mixin(__traits(identifier, T) ~ " " ~
to!string(tolower(__traits(identifier, T)[0])) ~
__traits(identifier, T)[1..$] ~ ";");
What if foo::bar were an alias for __traits(foo, bar) ?
The code would look like this:
mixin(T::identifier ~ " " ~
to!string(tolower(T::identifier[0])) ~
T::identifier[1..$] ~ ";");
What do you think?
Another uses:
__traits(int, isArithmetic) ==> int::isArithmetic
__traits(C, isAbstractClass) ==> C::isAbstractClass
__traits(hasMember, S, "m") ==> S::hasMember("m")
Well, you get the idea...
:: might be applied to other compile time uses, but I just came up with
this...
Hmn, interesting idea! I noticed, however, that the "foo" and "bar" in
your example are actually swapped...
__traits(foo, bar) ==> foo::bar
should be
__traits(foo, bar) ==> bar::foo
For many the uses of __traits I can recall off the top of my head, it
certainly seems to be both elegant and intuitive. One sore thumb would
be __traits(compiles, ...) which I believe gets used quite frequently in
Phobos.
Clarifications and my lack of insight into the complete breadth of
__traits's capabilities and variations aside, I think this is the best
suggestion for the replacement of the much maligned experimental keyword
that I have seen posted since Don's suggestion of a magic namespace[1].
I'm not 100% sure if this :: syntax could also tidy up is() expressions
too, but if it can, I can imagine it having a lot of support. If
language design was a democracy, I'd certainly vote for it ^^
A...
[1] Search the NG for "Proposal: Replace __traits and is(typeof(XXX))
with a 'magic namespace'."
Damn I type slow ><
