Walter Bright wrote:
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.
On 03/30/2011 10:30 PM, KennyTM~ wrote:
On Mar 31, 11 11:24, Andrei Alexandrescu wrote:
On 3/30/11 8:42 PM, Ary Manzana wrote:
I just hate it when you have to write too much to get simple things
done.
Does this type have a member? Current approach:
1. import std.traits;
2. invoke hasMember!(S
On 03/30/2011 11:20 PM, Luca Boasso wrote:
Hello,
I will move from California to Italy tomorrow so I will not be able to
read new posts.
As soon as I arrive home I'll read and respond to any reviews.
Thank you
Luca Boasso
Have a safe trip!
Andrei
On 03/30/2011 08:15 AM, 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'
Hello,
I will move from California to Italy tomorrow so I will not be able to
read new posts.
As soon as I arrive home I'll read and respond to any reviews.
Thank you
Luca Boasso
On 3/29/11, Luca Boasso wrote:
> Hello,
>
> thank you very much for your useful comments.
>
> I have updated the
On Mar 31, 11 11:24, Andrei Alexandrescu wrote:
On 3/30/11 8:42 PM, Ary Manzana wrote:
I just hate it when you have to write too much to get simple things
done.
Does this type have a member? Current approach:
1. import std.traits;
2. invoke hasMember!(S, "m")
Another approach:
1. I have the
On 3/30/11 8:42 PM, Ary Manzana wrote:
I just hate it when you have to write too much to get simple things
done.
Does this type have a member? Current approach:
1. import std.traits;
2. invoke hasMember!(S, "m")
Another approach:
1. I have the type, let's ask it: S::hasMember("m")
Map's thou
On Mar 31, 11 10:38, KennyTM~ wrote:
On Mar 31, 11 09:42, Ary Manzana wrote:
I just hate it when you have to write too much to get simple things
done.
Does this type have a member? Current approach:
1. import std.traits;
2. invoke hasMember!(S, "m")
Another approach:
1. I have the type, let'
TLS takes some time to getting used to. Doing multithreading in a way
forces me to stop using globals, because I always get bitten when
spawning new threads and only later realizing that my globals have
been re-initialized to their .init value. The new thread ends up
reading mostly zero-initialized
On 2011-03-30 19:38, KennyTM~ wrote:
> On Mar 31, 11 09:42, Ary Manzana wrote:
> > I just hate it when you have to write too much to get simple things
> > done.
> >
> > Does this type have a member? Current approach:
> >
> > 1. import std.traits;
> > 2. invoke hasMember!(S, "m")
> >
> > Another
On Mar 31, 11 09:42, Ary Manzana wrote:
I just hate it when you have to write too much to get simple things
done.
Does this type have a member? Current approach:
1. import std.traits;
2. invoke hasMember!(S, "m")
Another approach:
1. I have the type, let's ask it: S::hasMember("m")
Map's tho
bearophile Wrote:
> Regarding expression templates in C++ and D there is something to be
> considered (this was probably already discussed in past, but probably not by
> me). D is or hopes to become a language quite fit for numerics processing
> too. Features like vectors ops, multiple dimensio
On 3/30/2011 9:46 PM, Andrei Alexandrescu wrote:
Agreed. Andrei's opinion is understandable if he thinks he'd have to
implement these features and has better things to do. I'd be willing to
do the implementation work if the relevant compiler bugs/enhancements
(2443, 4707, and maybe support for in
Andrei Alexandrescu Wrote:
> On 3/29/11 4:37 PM, so wrote:
> [snip]
> > I find his posts among the most informative.
>
> I don't meant to offend anyone here but I think it's worth making a
> point for your benefit and others'. If you are interested in programming
> language theory, probably the
On 3/30/11 7:05 PM, dsimcha wrote:
On 3/30/2011 7:56 PM, bearophile wrote:
Jonathan M Davis:
Andrei is currently against making range-based functions work with
opApply
because of the resulting increase complexity of the implementations.
They were
really meant for ranges, not opApply. That does
On 03/30/2011 09:45 PM, KennyTM~ wrote:
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::
I just hate it when you have to write too much to get simple things
done.
Does this type have a member? Current approach:
1. import std.traits;
2. invoke hasMember!(S, "m")
Another approach:
1. I have the type, let's ask it: S::hasMember("m")
Map's thought to code.
My problem is that when you
On 03/30/2011 09:28 PM, 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, ba
Regarding expression templates in C++ and D there is something to be considered
(this was probably already discussed in past, but probably not by me). D is or
hopes to become a language quite fit for numerics processing too. Features like
vectors ops, multiple dimensional dollars symbols, array
Jose Armando Garcia Wrote:
> Why am I getting this error? I suspect that synchronized is the
> problem.
A synchronized class is implicitly shared and most of the methods are
synchronized. I say most because at a minimum, the constructor isn't
synchronized on anything. As you probably know sh
On 2011-03-30 17:17, Daniel Gibson wrote:
> Am 31.03.2011 01:57, schrieb dsimcha:
> > On 3/30/2011 6:24 PM, bearophile wrote:
> >> Andrei:
> >>> Beyond naming:
> >> Some standard for member attributes? Like m_something, etc? I don't
> >> like this a lot, but having a style guide on this too is usef
Am 31.03.2011 01:57, schrieb dsimcha:
On 3/30/2011 6:24 PM, bearophile wrote:
Andrei:
Beyond naming:
Some standard for member attributes? Like m_something, etc? I don't
like this a lot, but having a style guide on this too is useful for
Phobos (and user code).
Bye,
bearophile
I think the
On 2011-03-30 17:05, dsimcha wrote:
> On 3/30/2011 7:56 PM, bearophile wrote:
> > Jonathan M Davis:
> >> Andrei is currently against making range-based functions work with
> >> opApply because of the resulting increase complexity of the
> >> implementations. They were really meant for ranges, not o
On 3/30/2011 7:56 PM, bearophile wrote:
Jonathan M Davis:
Andrei is currently against making range-based functions work with opApply
because of the resulting increase complexity of the implementations. They were
really meant for ranges, not opApply. That doesn't necessarily mean that it's
a gua
On 3/30/2011 6:24 PM, bearophile wrote:
Andrei:
Beyond naming:
Some standard for member attributes? Like m_something, etc? I don't like this a
lot, but having a style guide on this too is useful for Phobos (and user code).
Bye,
bearophile
I think the style guide should be focused mostly (
Jonathan M Davis:
> Andrei is currently against making range-based functions work with opApply
> because of the resulting increase complexity of the implementations. They
> were
> really meant for ranges, not opApply. That doesn't necessarily mean that it's
> a guaranteed "we don't want to do
Andrej Mitrovic:
> How about not inventing new syntaxes? Leave that to C++7xFF.
Sorry for not being clear, by "alternative syntaxes" I meant something like the
"meta" namespace too.
Bye,
bearophile
KennyTM~ Wrote:
> On Mar 31, 11 06:34, Jason House wrote:
> > he compiler wants "argument types () shared" instead of "argument types
> > ()". It's an awful error message, and I'm certain I filed a bug for it at
> > least a year ago. In the toy example, mark the destructor as shared, and it
> >
On 2011-03-30 11:22, dsimcha wrote:
> == 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
On 2011-03-30 07:42, David Nadlinger wrote:
> 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 w
On Mar 31, 11 06:34, Jason House wrote:
he compiler wants "argument types () shared" instead of "argument types ()".
It's an awful error message, and I'm certain I filed a bug for it at least a year ago. In the toy
example, mark the destructor as shared, and it should compile.
Yes you have. h
On 2011-03-30 15:27, Andrei Alexandrescu wrote:
> On 3/30/11 5:24 PM, bearophile wrote:
> > Andrei:
> >> Beyond naming:
> > Some standard for member attributes? Like m_something, etc? I don't like
> > this a lot, but having a style guide on this too is useful for Phobos
> > (and user code).
> >
>
On Mar 31, 11 06:32, Ary Manzana wrote:
On 3/30/11 5:52 PM, KennyTM~ wrote:
On Mar 31, 11 04:19, Alix Pexton wrote:
On 30/03/2011 20:45, KennyTM~ wrote:
This is confusing as :: is used to separate scopes in C++ (and PHP
too).
The first thing it reminded me of was Lua, where a single colon ma
How about not inventing new syntaxes? Leave that to C++7xFF.
Ary Manzana:
> Why make *anything* hard to use if you can do it in an easier way?
I agree. On the other hand is the :: syntax easy compared to a "meta."
namespace? The meta name is more readable. I suggest to try to invent few more
alternative syntaxes before choosing.
Bye,
bearophile
On 3/30/11 5:52 PM, KennyTM~ wrote:
On Mar 31, 11 04:19, Alix Pexton wrote:
On 30/03/2011 20:45, KennyTM~ wrote:
This is confusing as :: is used to separate scopes in C++ (and PHP too).
The first thing it reminded me of was Lua, where a single colon makes
the left hand side into the first arg
he compiler wants "argument types () shared" instead of "argument types ()".
It's an awful error message, and I'm certain I filed a bug for it at least a
year ago. In the toy example, mark the destructor as shared, and it should
compile.
Jose Armando Garcia Wrote:
> It looks like the following
On 3/30/11 5:24 PM, bearophile wrote:
Andrei:
Beyond naming:
Some standard for member attributes? Like m_something, etc? I don't like this a
lot, but having a style guide on this too is useful for Phobos (and user code).
Bye,
bearophile
I usually prepend private data members with an under
Dmitry Olshansky:
> > the second operand often is not a set, so I can't use operators.
> How's that ?
I meant in Python :-) That's the way it is designed, probably because of limits
of Python operator overloading.
Bye,
bearophile
Andrei:
> Beyond naming:
Some standard for member attributes? Like m_something, etc? I don't like this a
lot, but having a style guide on this too is useful for Phobos (and user code).
Bye,
bearophile
I read your "Curl RFC" thread, great job. Somehow I missed it when it
was originaly posted.
As you stated earlier, you plan to continue working on your curl
wrapper, so to boost my proposal usefullness I think it needs to
address unsolved problems.
Could you please be more specific about you
On 2011-03-30 11:19, Daniel Gibson wrote:
> 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
On 31.03.2011 0:39, Daniel Gibson wrote:
Am 30.03.2011 22:34, schrieb Dmitry Olshansky:
On 30.03.2011 2:14, so wrote:
On Tue, 29 Mar 2011 22:56:10 +0300, dsimcha wrote:
Occasionally i encounter this argument that operator overloading is
bad thing when it is abused.
I don't overload operators
On 29.03.2011 17:11, spir wrote:
On 03/29/2011 02:16 PM, KennyTM~ wrote:
On Mar 29, 11 18:56, bearophile wrote:
Dmitry Olshansky:
Others (except (?P) and (?P=name) ) also considered common
extensions
and I planed to add them plus regex comment (#...) where all of ...
simply
have no effect o
import std.stdio;
class B
{
private File file;
}
synchronized class A
{
private File file;
}
void main()
{
}
/usr/include/d/dmd/phobos/std/stdio.d(292): Error: destructor
std.stdio.File.~this () is not callable using argument types ()
Why am I getting this error? I suspect that synchronized
It looks like the following works:
struct B {}
synchronized class A { private B b }
but this doesn't:
struct B { ~this() {} }
synchronized class A { private B b }
On Wed, Mar 30, 2011 at 4:59 PM, Jose Armando Garcia wrote:
> import std.stdio;
>
> class B
> {
> private File file;
> }
> synchro
On Mar 31, 11 04:19, Alix Pexton wrote:
On 30/03/2011 20:45, KennyTM~ wrote:
This is confusing as :: is used to separate scopes in C++ (and PHP too).
The first thing it reminded me of was Lua, where a single colon makes
the left hand side into the first argument of the function on the right.
On Mar 31, 11 04:35, Jonathan M Davis wrote:
> 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.
This woul
Am 30.03.2011 22:34, schrieb Dmitry Olshansky:
On 30.03.2011 2:14, so wrote:
On Tue, 29 Mar 2011 22:56:10 +0300, dsimcha wrote:
Occasionally i encounter this argument that operator overloading is
bad thing when it is abused.
I don't overload operators offensively myself, i use dot(vec, vec)
cr
Am 30.03.2011 20:35, schrieb Jacob Carlborg:
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
On 2011-03-30 13:07, Andrei Alexandrescu wrote:
> 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,
On 30.03.2011 2:14, so wrote:
On Tue, 29 Mar 2011 22:56:10 +0300, dsimcha wrote:
Occasionally i encounter this argument that operator overloading is
bad thing when it is abused.
I don't overload operators offensively myself, i use dot(vec, vec)
cross(vec, vec) for example because there is not
On 30.03.2011 1:02, bearophile wrote:
the second operand often is not a set, so I can't use operators.
How's that ?
Implementing simplistic vector struct I made * to work on both vectors
(meaning dot product) and scalars (meaning scaling).
Template constraints + opBinaryRight for the win!
P.
On 30/03/2011 20:45, KennyTM~ wrote:
This is confusing as :: is used to separate scopes in C++ (and PHP too).
The first thing it reminded me of was Lua, where a single colon makes
the left hand side into the first argument of the function on the right.
foo:bar(x) ==> bar.(foo, x)
So it felt
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::
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)
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
"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 r
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 ex
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)
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
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
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:
ht
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-
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
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?
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 t
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.
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.
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 tak
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 a
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 ca
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:
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 sing
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
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
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 GSo
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
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
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 fol
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 ve
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 in
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
== 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. H
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
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 TDP
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 w
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 interest
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 modu
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?
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 cann
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.co
>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
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 struc
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 a
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
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
> * Add
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 ag
>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 do
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
1 - 100 of 154 matches
Mail list logo
