On 11/08/2015 4:20 a.m., karabuta wrote:
On Monday, 10 August 2015 at 04:07:05 UTC, Rikki Cattermole wrote:
On 10/08/2015 5:29 a.m., karabuta wrote:
[...]
I have two separate plans right now for how to grow D.
The first related to GUI's and game development is going very well.
Although it'll
On Monday, 10 August 2015 at 04:07:05 UTC, Rikki Cattermole wrote:
On 10/08/2015 5:29 a.m., karabuta wrote:
[...]
I have two separate plans right now for how to grow D.
The first related to GUI's and game development is going very
well. Although it'll take atleast another year before you
sho
GUI, ...). I think a lot has been done already and
> > I suggest focus should be centered on making them stable.
> > Sadly, some have even been abandoned after all the work that
> > went in to them (no names).
> >
> > Already contribution is not much, so I believe s
On Sunday, 9 August 2015 at 17:29:08 UTC, karabuta wrote:
A lot of request are made most often about what needs to be
added in D and what is lacking (multiple compilers, debugging
tools, IDEs, GUI, ...). I think a lot has been done already and
I suggest focus should be centered on making them
On 10/08/2015 5:29 a.m., karabuta wrote:
A lot of request are made most often about what needs to be added in D
and what is lacking (multiple compilers, debugging tools, IDEs, GUI,
...). I think a lot has been done already and I suggest focus should be
centered on making them stable. Sadly, some
On Sunday, 9 August 2015 at 17:29:08 UTC, karabuta wrote:
A lot of request are made most often about what needs to be
added in D and what is lacking (multiple compilers, debugging
tools, IDEs, GUI, ...). I think a lot has been done already and
I suggest focus should be centered on making them
On 09-Aug-2015 20:29, karabuta wrote:
A lot of request are made most often about what needs to be added in D
and what is lacking (multiple compilers, debugging tools, IDEs, GUI,
...). I think a lot has been done already and I suggest focus should be
centered on making them stable. Sadly, some
A lot of request are made most often about what needs to be added
in D and what is lacking (multiple compilers, debugging tools,
IDEs, GUI, ...). I think a lot has been done already and I
suggest focus should be centered on making them stable. Sadly,
some have even been abandoned after all the
On Monday, 21 January 2013 at 19:43:15 UTC, Rob T wrote:
On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic
wrote:
Bottom line is, the module system and access specifiers can
use some
improvements. Language XYZ might do something in its own way,
but D is
a language of its own and we s
On 1/21/13 9:41 AM, Andrej Mitrovic wrote:
On 1/21/13, deadalnix wrote:
Package have nothing to do with the private discussion that take
place here.
It's completely relevant.
FWIW I think they are distinct issues.
Andrei
On 1/21/13 7:49 AM, eles wrote:
Why make access protection dependent of how the source code is spread
into files?
For the simple reason that files are the de facto unit of encapsulation
for viewing and editing.
Andrei
On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic wrote:
Bottom line is, the module system and access specifiers can use
some
improvements. Language XYZ might do something in its own way,
but D is
a language of its own and we should feel free to innovate.
Yes modules can be improved
C++ does not have UFCS. It does matter.
On Monday, 21 January 2013 at 14:46:52 UTC, deadalnix wrote:
On Monday, 21 January 2013 at 14:34:50 UTC, eles wrote:
Every time you change something people are used too, they get
scared. Someone scared by a change they don't understand will
not use D anyway. Given another behavior of private mo
On Monday, 21 January 2013 at 14:34:50 UTC, eles wrote:
Just think about Andrey as being such C++ programmer that gave
D a try and ran away. Why? Because it was puzzled to see that,
despit being "private", the attribute is "public" (well, to
some degree).
His first thought was that D should n
On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic wrote:
On 1/21/13, Peter Alexander
wrote:
This is being blown completely out of proportion.
I don't think so.
Consider that currently it's impossible to hide any symbols
from a
user if they are located in subpackages. Which means y
On Monday, 21 January 2013 at 14:29:32 UTC, deadalnix wrote:
On Monday, 21 January 2013 at 14:06:49 UTC, eles wrote:
On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:
On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright
wr
On Monday, 21 January 2013 at 14:06:49 UTC, eles wrote:
On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:
On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright
wrote:
On 1/18/2013 2:16 PM, Andrey wrote:
What would be the p
On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:
On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright
wrote:
On 1/18/2013 2:16 PM, Andrey wrote:
What would be the point ? You'll have the implementation and
the function d
On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright wrote:
On 1/18/2013 2:16 PM, Andrey wrote:
This is by design, not a bug. All code in a module has access
to all private members in that same module. This obviates the
need for the
On Monday, 21 January 2013 at 13:16:03 UTC, Peter Alexander wrote:
On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:
On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright
wrote:
On 1/18/2013 4:55 PM, Andrey wrote:
- Lots of languages don't have access control at all, yet
somehow pe
On Monday, 21 January 2013 at 13:32:35 UTC, eles wrote:
On Monday, 21 January 2013 at 13:16:03 UTC, Peter Alexander
wrote:
On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:
On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright
wrote:
On 1/18/2013 4:55 PM, Andrey wrote:
In the begin
On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:
On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright
wrote:
On 1/18/2013 4:55 PM, Andrey wrote:
This all falls apart once you decide you need "friend" access.
What is wrong with this POV is that the original class no
longer has a
On Monday, 21 January 2013 at 12:31:16 UTC, Russel Winder wrote:
On Mon, 2013-01-21 at 09:34 +0100, Paulo Pinto wrote:
[…]
Yes. I remember looking at Groovy around 2000 timeframe and
not giving
too much consideration.
[…]
Just to ensure the history as determined by Google search is at
least
On Monday, 21 January 2013 at 10:42:17 UTC, deadalnix wrote:
On Monday, 21 January 2013 at 08:34:49 UTC, Paulo Pinto wrote:
Go might eventually succeed in replacing C, Google just needs
to make Go a first class language for Android development.
Go has no chance to replace C as too many low l
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
[…]
This D development community should put effort into making GDC
and LDC
the primary D tools, ensuring that the latest D version is
always
I second that.
On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright wrote:
On 1/18/2013 4:55 PM, Andrey wrote:
This all falls apart once you decide you need "friend" access.
What is wrong with this POV is that the original class no longer
has a word to say if she wants to be friended by someone.
In
On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright wrote:
On 1/18/2013 2:16 PM, Andrey wrote:
This is by design, not a bug. All code in a module has access
to all private members in that same module. This obviates the
need for the C++ "friend" declarations.
Yes, but that is a bad choi
On Mon, 2013-01-21 at 09:34 +0100, Paulo Pinto wrote:
[…]
> Yes. I remember looking at Groovy around 2000 timeframe and not
> giving
> too much consideration.
[…]
Just to ensure the history as determined by Google search is at least
fairly reasonable, Groovy started in mid to late 2003 had a hicc
On Monday, 21 January 2013 at 08:34:49 UTC, Paulo Pinto wrote:
Go might eventually succeed in replacing C, Google just needs
to make Go a first class language for Android development.
Go has no chance to replace C as too many low level features are
missing. But yes, it can become pretty big
On Saturday, 19 January 2013 at 18:43:45 UTC, SomeDude wrote:
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder
wrote:
On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
[…]
(*) Groovy managed to use a 6 year rather than 10 cycle to real
usability, but it was only when SpringSource b
On 1/19/13 1:36 PM, Walter Bright wrote:
On 1/19/2013 5:57 AM, Andrei Alexandrescu wrote:
On 1/19/13 8:21 AM, Maxim Fomin wrote:
How much chances does this program have?
--mylib.di
class A
{
public int i;
}
void foo(A a);
-mylib.d-
class A
{
public int i;
privat
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
[…]
(*) Groovy managed to use a 6 year rather than 10 cycle to real
usability, but it was only when SpringSource bought G2One and
started
putting resource into Groovy that it r
On 1/19/2013 5:57 AM, Andrei Alexandrescu wrote:
On 1/19/13 8:21 AM, Maxim Fomin wrote:
How much chances does this program have?
--mylib.di
class A
{
public int i;
}
void foo(A a);
-mylib.d-
class A
{
public int i;
private int ii;
}
Looks like an ODR violation,
In theory and according to the OOP concept they might not be
needed but when it comes to actually implement a OO concept it
can turn out to be handy to have. That is, accessing a private
member in the same module.
Allright. But I don't see a reason why this coudln't be done with
nested classe
Am 19.01.2013 16:26, schrieb Jacob Carlborg:
On 2013-01-19 03:50, Andrey wrote:
I haven't seen such situations yet. According to OOP concept they must
be very rare, so I tend to consider them more of architecture and logic
mistake (and C++ is one big architecture and logic frankenstein).
In t
On 2013-01-19 03:50, Andrey wrote:
I haven't seen such situations yet. According to OOP concept they must
be very rare, so I tend to consider them more of architecture and logic
mistake (and C++ is one big architecture and logic frankenstein).
In theory and according to the OOP concept they mi
Am 19.01.2013 14:19, schrieb Freddie Chopin:
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
This D development community should put effort into making GDC and LDC
the primary D tools
For example Go (developed since 2009) is already integrated with GCC
(since 4.6.3 so for so
On 1/19/13 9:23 AM, Maxim Fomin wrote:
On Saturday, 19 January 2013 at 13:57:02 UTC, Andrei Alexandrescu wrote:
On 1/19/13 8:21 AM, Maxim Fomin wrote:
How much chances does this program have?
Looks like an ODR violation, but oddly there's nothing stopping us
from making this work. It's a good
On Saturday, 19 January 2013 at 13:57:02 UTC, Andrei Alexandrescu
wrote:
On 1/19/13 8:21 AM, Maxim Fomin wrote:
How much chances does this program have?
Looks like an ODR violation, but oddly there's nothing stopping
us from making this work. It's a good idea to pursue.
Andrei
Unfortunately
On 1/19/13 8:21 AM, Maxim Fomin wrote:
How much chances does this program have?
--mylib.di
class A
{
public int i;
}
void foo(A a);
-mylib.d-
class A
{
public int i;
private int ii;
}
Looks like an ODR violation, but oddly there's nothing stopping us from
makin
On Saturday, 19 January 2013 at 13:12:32 UTC, Andrei Alexandrescu
wrote:
On 1/19/13 2:35 AM, Maxim Fomin wrote:
On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe
wrote:
On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
So how am I supposed to hide the variable inside the str
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
This D development community should put effort into making GDC
and LDC
the primary D tools
For example Go (developed since 2009) is already integrated with
GCC (since 4.6.3 so for some time)... I know that it's google and
stu
On 1/19/13 2:35 AM, Maxim Fomin wrote:
On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:
On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
So how am I supposed to hide the variable inside the struct or class?
I'm sure "friend" explodes the basics of OOP encapsulat
On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
[…]
> If that's an optimization, and most people are going to use LDC
> or GDC in future, why is Walter working on that stuff?
Working on a separate backend is fine if that is what people want to do.
I think though that unless D sits on GCC or
Andrei Alexandrescu:
I agree with the sentiment but let's not use oblique rhetorical
questions to drive a point.
Those questions aren't fully rhetorical because I don't know
those answers and I'd like to know. I don't know why Walter
thinks removing bit intrisics is more urgent than working
On Saturday, 19 January 2013 at 02:50:35 UTC, Andrey wrote:
This all falls apart once you decide you need "friend" access.
I haven't seen such situations yet. According to OOP concept
they must be very rare, so I tend to consider them more of
architecture and logic mistake (and C++ is one big
Am 19.01.2013 03:50, schrieb Andrey:
This all falls apart once you decide you need "friend" access.
I haven't seen such situations yet. According to OOP concept they must
be very rare, so I tend to consider them more of architecture and logic
mistake (and C++ is one big architecture and logic f
On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:
On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
So how am I supposed to hide the variable inside the struct or
class?
I'm sure "friend" explodes the basics of OOP encapsulation
mechanics.
http://www.parashift.co
nyway, just wanted to say that this thread got off topic in an
>> awful hurry.
>
>
> It sort of funny that the thread started off with a complaint
> about Walters lack of focus and quickly got off topic. Maybe
> lack of focus is a common attribute of people interested
snip
Anyway, just wanted to say that this thread got off topic in an
awful hurry.
It sort of funny that the thread started off with a complaint
about Walters lack of focus and quickly got off topic. Maybe
lack of focus is a common attribute of people interested in D.
I suggested that D be
That is also the way to go IMO.
snip
This isn't directed at you, or any other poster for that matter
(I am to technically inept to figure out how to post to the
thread other than using the 'reply' feature)...
Anyway, just wanted to say that this thread got off topic in an
awful hurry.
On Saturday, 19 January 2013 at 03:40:35 UTC, Walter Bright wrote:
On 1/18/2013 6:50 PM, Andrey wrote:
And for that reason we have a simple helper "friend" in C++.
C++ friends are quite complex and are a giant pain. D's method
of everything in a module being implicitly a friend has been
work
On 1/18/2013 6:50 PM, Andrey wrote:
And for that reason we have a simple helper "friend" in C++.
C++ friends are quite complex and are a giant pain. D's method of everything in
a module being implicitly a friend has been working very well for 10 years now.
On 01/19/2013 01:04 AM, Andrey wrote:
MyStruct ms;
ms.a = 42; //!!!
writeln(ms.a);
This is by design, not a bug. All code in a module has access to all
private members in that same module. This obviates the need for the
C++ "friend" declarations.
Wikipedia states:
«In general, encapsulation
This all falls apart once you decide you need "friend" access.
I haven't seen such situations yet. According to OOP concept they
must be very rare, so I tend to consider them more of
architecture and logic mistake (and C++ is one big architecture
and logic frankenstein).
Once again, in D yo
On 1/18/2013 4:55 PM, Andrey wrote:
Are nested classes quite more perfectly suited for this? In my containers I
implement iterator interface using nested class. Then I can easily construct
mycontainer.new Iterator and have (should have by theory) access to protected
(not private) members. Also I
«Actually I made up the term "object-oriented", and I can tell
you I did not have C++ in mind.» Alan Key.
Kay, of course. Alan Curtis Kay. Sorry for my english. :-)
On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:
On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
So how am I supposed to hide the variable inside the struct or
class?
Generally the D answer here is to put them in separate files.
The module (file) is the main D en
On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
So how am I supposed to hide the variable inside the struct or
class?
Generally the D answer here is to put them in separate files. The
module (file) is the main D encapsulation unit rather than the
class/struct.
It isn't the same
MyStruct ms;
ms.a = 42; //!!!
writeln(ms.a);
This is by design, not a bug. All code in a module has access
to all private members in that same module. This obviates the
need for the C++ "friend" declarations.
Wikipedia states:
«In general, encapsulation is one of the 4 fundamentals of OOP
On Fri, Jan 18, 2013 at 05:43:16PM -0500, Andrei Alexandrescu wrote:
> On 1/18/13 3:21 PM, bearophile wrote:
[...]
> I agree with the sentiment but let's not use oblique rhetorical
> questions to drive a point.
>
> Allow me to extend again the invitation to participate to the
> development by cont
On 1/18/13 3:21 PM, bearophile wrote:
Do you know why Walter is currently working on this stuff? Is this an
optimization? If it's an optimization, do you know why it is more
important than implementing "scope" or an unpacking syntax for tuples?
https://github.com/D-Programming-Language/dmd/commi
On 1/18/2013 2:16 PM, Andrey wrote:
I'm now still on 2.060 release, and I was shocked when suddenly have discovered
that member visibility and access attributes just don't work! Well, 2060
release, and I can easily compile such thing:
struct MyStruct {
private int a;
}
MyStruct ms;
ms.a = 4
Me and many others consider D as consistent, free and clever
replacement for screwed(IMHO) C++. From that perspective the
current design of D already has necessary things. I would like
developers to focus on fixing issues and polishing everything
rather than trying to implement something new
On Friday, 18 January 2013 at 20:21:47 UTC, bearophile wrote:
Also, I don't agree a lot about the "fog of war" theory by
Walter.
I must have missed that one, what's it about?
I think a development plan should be discussed, written down,
and then followed (and dynamically fixed, when necessary
Do you know why Walter is currently working on this stuff? Is
this an optimization? If it's an optimization, do you know why it
is more important than implementing "scope" or an unpacking
syntax for tuples?
https://github.com/D-Programming-Language/dmd/commit/fc4462b95307d5c31d4c0bcf830faf6686
On Friday, 21 December 2012 at 18:34:12 UTC, Rob T wrote:
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman
wrote:
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging branch in addition to the master branch. From
what I understa
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman
wrote:
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging branch in addition to the master branch. From
what I understand, the idea seems to be to vet a release on
staging until
On Thursday, 20 December 2012 at 23:43:12 UTC, Joseph Cassman
wrote:
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
I agree with one "stable" branch.
Andrei
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
I agree with one "stable" branch.
Andrei
Just some food for thought.
In the section about the "Branching model", the wiki currently
has a staging branch in addition to the master branch. From what
I understand, the
On Thursday, 20 December 2012 at 08:27:22 UTC, foobar wrote:
I see both as going hand-in-hand, otherwise we have chicken-egg
problem.
We need a better process to allow more developers to contribute
code more easily *and* we need better planning to provide
incentive for new developer to contribu
On Thursday, 20 December 2012 at 05:32:30 UTC, H. S. Teoh wrote:
>On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix
>wrote:
>
>>master : used as a base for development. New feature are
>>merged
>>here.
>>staging : used to provide a view of what the next version
>>will
>>look like. Re
of things, and from that experience the other big holes
will become easier to pick out and deal with.
I think we have to keep it simple for now, focus on a dev,
staging, release process, implement something, work out the
bugs, get people used to having it, and prove the value, then
we can
On Thursday, 20 December 2012 at 05:32:30 UTC, H. S. Teoh wrote:
On Thu, Dec 20, 2012 at 05:48:13AM +0100, deadalnix wrote:
On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips
In my mind, after a release, the contents of staging are
updated to be
exactly the same as master. This can b
ill become easier to pick out and deal with.
I think we have to keep it simple for now, focus on a dev,
staging, release process, implement something, work out the bugs,
get people used to having it, and prove the value, then we can
get on with tackling the other major issues in a similar way.
On Thu, Dec 20, 2012 at 05:48:13AM +0100, deadalnix wrote:
> On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips wrote:
> >On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote:
> >
> >>master : used as a base for development. New feature are merged
> >>here.
> >>staging : used
On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips
wrote:
From the sound of it this request is pulled into master. We
continue to pull many of these changes in. How do we decide
they should be placed into staging, when we pull them into
master?. If we wait for some 'magic time' how
On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips
wrote:
On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote:
master : used as a base for development. New feature are
merged here.
staging : used to provide a view of what the next version will
look like. Regular snapshot
On Wednesday, 19 December 2012 at 23:05:59 UTC, deadalnix wrote:
master : used as a base for development. New feature are merged
here.
staging : used to provide a view of what the next version will
look like. Regular snapshot of that branch are made so public
can use the last features.
version
On Wednesday, 19 December 2012 at 23:08:59 UTC, Andrei
Alexandrescu wrote:
My understanding is that's what many projects do. Supporting
each minor release would make for a ton of work.
The whole point is to not support all minor release. Usually
project supports one or 2 of them, that's it.
On 12/19/12 5:43 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 22:30:29 UTC, Andrei Alexandrescu wrote:
On 12/19/12 5:07 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei Alexandrescu
wrote:
Walter needs to chime in about that. One possibility is to continue
On Wednesday, 19 December 2012 at 22:30:29 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 5:07 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei
Alexandrescu wrote:
Walter needs to chime in about that. One possibility is to
continue
using tags for marking releases, and th
On Wednesday, 19 December 2012 at 22:30:29 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 5:07 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei
Alexandrescu wrote:
Walter needs to chime in about that. One possibility is to
continue
using tags for marking releases, and th
On 12/19/12 5:07 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei Alexandrescu wrote:
Walter needs to chime in about that. One possibility is to continue
using tags for marking releases, and then branch for the few important
releases that we want to patch.
Note that
On Wednesday, 19 December 2012 at 21:53:04 UTC, H. S. Teoh wrote:
On Wed, Dec 19, 2012 at 04:48:22PM -0500, Andrei Alexandrescu
wrote:
On 12/19/12 4:40 PM, deadalnix wrote:
>On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
>Alexandrescu wrote:
>>On 12/19/12 4:23 PM, foobar wrote:
[...]
On Wednesday, 19 December 2012 at 21:58:12 UTC, foobar wrote:
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix
wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wro
On Wednesday, 19 December 2012 at 21:48:22 UTC, Andrei
Alexandrescu wrote:
Walter needs to chime in about that. One possibility is to
continue using tags for marking releases, and then branch for
the few important releases that we want to patch.
Note that what is described on the wiki distin
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix
wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" branch?
No. St
On Wed, Dec 19, 2012 at 04:48:22PM -0500, Andrei Alexandrescu wrote:
> On 12/19/12 4:40 PM, deadalnix wrote:
> >On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei Alexandrescu wrote:
> >>On 12/19/12 4:23 PM, foobar wrote:
[...]
> >>>Let's generalize this point for the sake of reaching consensus
On 12/19/12 4:40 PM, deadalnix wrote:
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree th
On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei
Alexandrescu wrote:
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix
wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" branch?
No. St
On 12/19/12 4:23 PM, foobar wrote:
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" branch?
No. Stable isn't a boolean criteria. You'll find different degree of
stability goi
On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
Do we all agree that we need a "stable" branch?
No. Stable isn't a boolean criteria. You'll find different
degree of stability going from not so stable (dev version)
On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
On Wednesday, 19 December 2012 at 19:26:48 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei
Alexandrescu wrote:
I was hoping for more consensus to build in this thread.
Right now it seems there's still quit
On Wed, Dec 19, 2012 at 02:01:57PM -0500, Andrei Alexandrescu wrote:
> On 12/19/12 1:45 PM, H. S. Teoh wrote:
> >On Fri, Dec 14, 2012 at 10:16:45AM -0500, Andrei Alexandrescu wrote:
> >>On 12/14/12 10:02 AM, H. S. Teoh wrote:
> >>>A number of us have put up a draft of a proposed release process on
On Wednesday, 19 December 2012 at 19:26:48 UTC, deadalnix wrote:
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei
Alexandrescu wrote:
I was hoping for more consensus to build in this thread. Right
now it seems there's still quite a bit of controversy about
what the best way to go is.
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei
Alexandrescu wrote:
I was hoping for more consensus to build in this thread. Right
now it seems there's still quite a bit of controversy about
what the best way to go is.
I'm afraid a lot of discussions we see right now are plain
useles
On Wednesday, 19 December 2012 at 19:01:56 UTC, Andrei
Alexandrescu wrote:
I was hoping for more consensus to build in this thread. Right
now it seems there's still quite a bit of controversy about
what the best way to go is.
Andrei
We need to list out all the main points of contention and
On 12/19/12 1:45 PM, H. S. Teoh wrote:
On Fri, Dec 14, 2012 at 10:16:45AM -0500, Andrei Alexandrescu wrote:
On 12/14/12 10:02 AM, H. S. Teoh wrote:
A number of us have put up a draft of a proposed release process on
the wiki, based on some of the things discussed in this thread.
http:/
1 - 100 of 228 matches
Mail list logo
