On 2013-05-21 22:36, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
All directories have executable permission set.
--
/Jacob Carlborg
On 5/22/2013 11:55 PM, Jacob Carlborg wrote:
On 2013-05-21 22:36, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
All directories have executable
On 2013-05-23 09:08, Walter Bright wrote:
Is this the case with previous zips, or is it new for this one?
Never mind. It was my tool. I tried a different one and it's not
executable there.
--
/Jacob Carlborg
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
just filed a regression from 062 to 063:
http://d.puremagic.com/issues/show_bug.cgi?id=10141
it only affects error message though (giving a nonsensical error message).
Digression:
I used dustmite to reduce it (awesome tool) down to 6 files, but then had
to further manually reduce to 1 file.
I
On Thursday, 23 May 2013 at 09:05:02 UTC, Don wrote:
This means that the const variable x has been initialized TWICE!
That's no different from non-const members.
struct Foo { int x = 1; }
Foo f = Foo(2); // f.x is 2
The initialiser is a default value if you don't provide one in
the
On 05/23/13 11:05, Don wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is pretty
much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
On 21 May 2013 21:36, Walter Bright newshou...@digitalmars.com wrote:
Join the dmd beta mailing list to keep up with the betas. This one is pretty
much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
and another regression, this time more serious, that came up in my code:
http://d.puremagic.com/issues/show_bug.cgi?id=10148
Note, dustmite got stuck forever trying to reduce it, so i had to reduce
manually.
On Tue, May 21, 2013 at 1:36 PM, Walter Bright
newshou...@digitalmars.comwrote:
On Wednesday, 22 May 2013 at 13:44:10 UTC, Dicebot wrote:
Eh, official definition of breaking change keeps breaking my
heart. But I guess this is a mindset set in stone now and
changing it is close to impossible.
Can you elaborate a little bit?
I felt personally that what the discussion
On Thursday, 23 May 2013 at 12:18:14 UTC, Joseph Rushton Wakeling
wrote:
On Wednesday, 22 May 2013 at 13:44:10 UTC, Dicebot wrote:
Eh, official definition of breaking change keeps breaking my
heart. But I guess this is a mindset set in stone now and
changing it is close to impossible.
Can
On Tuesday, 21 May 2013 at 04:52:25 UTC, Diggory wrote:
Either way, at least on windows the separate process would have
to be persistent as creating a new process has a lot more
overhead attached to it than on posix systems. Implicitly
creating a child process is also something a D programmer
On Friday, 17 May 2013 at 13:28:20 UTC, Andrei Alexandrescu wrote:
Great talk. Vote up!
http://www.reddit.com/r/programming/comments/1eiku4/dconf_2013_day_1_talk_5_using_d_alongside_a_game/
Andrei
Nice talk, Manu! You
You have module constructors in mixins. How did you solve the
circular
On Thursday, 23 May 2013 at 10:17:00 UTC, Peter Alexander wrote:
On Thursday, 23 May 2013 at 09:05:02 UTC, Don wrote:
This means that the const variable x has been initialized
TWICE!
That's no different from non-const members.
It's perfectly OK to modify a non-const member as many times as
On Thursday, 23 May 2013 at 11:33:53 UTC, Timothee Cour wrote:
Note, dustmite got stuck forever trying to reduce it, so i had
to reduce
manually.
You may need to use Dustmite together with the timeout command
for cases when the test command may hang indefinitely:
On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:
On 05/23/13 11:05, Don wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas.
This one is pretty much good to go, unless something
disastrous crops up.
On 05/23/13 15:12, Don wrote:
On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:
On 05/23/13 11:05, Don wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless
On Thu, 23 May 2013 05:05:01 -0400, Don turnyourkidsintoc...@nospam.com
wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless something disastrous crops up.
On Thu, 23 May 2013 09:50:28 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 05/23/13 15:12, Don wrote:
On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:
struct Packet(uint TYPE) {
immutable uint type = TYPE;
// ...
}
But that allows you to write:
auto w =
On 23 May 2013 14:52, Steven Schveighoffer schvei...@yahoo.com wrote:
On Thu, 23 May 2013 05:05:01 -0400, Don turnyourkidsintoc...@nospam.com
wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty
something I may have actually used in real code writing a
low-level networking library:
struct Packet
{
immutable etherType = 0x0800; // IPv4 by default;
// ...
this(bool IPv6)
{
if (!IPv6)
return; // fine
On Thu, May 23, 2013 at 4:42 PM, Dicebot m.stras...@gmail.com wrote:
something I may have actually used in real code writing a low-level
networking library:
...
default template argument would sort that out wouldn't it?
On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer
wrote:
Seems like const qualifier for members is simply ignored inside
the ctor, it should only be ignored until it is set, or until
it is used.
I am quite sure I have seen it (mutability of immutable in
constructor) guaranteed
On Thursday, 23 May 2013 at 09:35:03 UTC, Timothee Cour wrote:
I wish dustmite could be improved to 'run the last mile' by
attempting to
merge files:
a.d:
import b;
b.d:
import c;
c.d:
//some stuff
dustmite should attempt to merge such files and reduce to:
a.d
// some stuff
Added!
On Thu, 23 May 2013 11:07:16 -0400, Dicebot m.stras...@gmail.com wrote:
On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:
Seems like const qualifier for members is simply ignored inside the
ctor, it should only be ignored until it is set, or until it is used.
I am quite
On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer
wrote:
On Thu, 23 May 2013 10:16:13 -0400, Iain Buclaw
ibuc...@ubuntu.com wrote:
On 23 May 2013 14:52, Steven Schveighoffer
schvei...@yahoo.com wrote:
Adding an initializer simply changes the default value from 0
to whatever
On Thu, May 23, 2013 at 5:06 PM, Dicebot m.stras...@gmail.com wrote:
On Thursday, 23 May 2013 at 14:56:14 UTC, Rory McGuire wrote:
On Thu, May 23, 2013 at 4:42 PM, Dicebot m.stras...@gmail.com wrote:
b) it requires to know your argument at compile-time. What if you packet
construction is
On 05/23/13 16:02, Steven Schveighoffer wrote:
On Thu, 23 May 2013 09:50:28 -0400, Artur Skawina art.08...@gmail.com wrote:
On 05/23/13 15:12, Don wrote:
On Thursday, 23 May 2013 at 11:08:16 UTC, Artur Skawina wrote:
struct Packet(uint TYPE) {
immutable uint type = TYPE;
// ...
}
On Thursday, 23 May 2013 at 13:52:49 UTC, Steven Schveighoffer
wrote:
On Thu, 23 May 2013 05:05:01 -0400, Don
turnyourkidsintoc...@nospam.com wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas.
This one is pretty
On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina art.08...@gmail.com
wrote:
If it wasn't clear - it is about the _language_, not what some compiler
currently happens to do. Being able to mutate /initialized/ immutables
is a bad idea. IOW you should not be able to modify 'Packet.type' above.
On 23 May 2013 19:05, Don turnyourkidsintoc...@nospam.com wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This one is
pretty much good to go, unless something disastrous crops up.
On 23 May 2013 15:54, Brad Anderson e...@gnuk.net wrote:
On Thursday, 23 May 2013 at 03:56:00 UTC, Nick Sabalausky wrote:
On Thu, 23 May 2013 02:08:15 +0200
Brad Anderson e...@gnuk.net wrote:
and one of the games featured prominently was Quantum Break by Manu's
very own Remedy Games. Any
On 23 May 2013 22:56, Max Samukha maxsamu...@gmail.com wrote:
On Friday, 17 May 2013 at 13:28:20 UTC, Andrei Alexandrescu wrote:
Great talk. Vote up!
http://www.reddit.com/r/**programming/comments/1eiku4/**
On Thu, 23 May 2013 12:09:26 -0400, Don turnyourkidsintoc...@nospam.com
wrote:
On Thursday, 23 May 2013 at 13:52:49 UTC, Steven Schveighoffer wrote:
On Thu, 23 May 2013 05:05:01 -0400, Don
turnyourkidsintoc...@nospam.com wrote:
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
On 5/23/13 9:12 AM, Don wrote:
No, it's not, it's a fix plus a new misfeature.
Don, you're wrong. The feature is sensible. The problem with it is that
it changes semantics of existing code.
Andrei
On 5/23/13 11:07 AM, Dicebot wrote:
On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:
Seems like const qualifier for members is simply ignored inside the
ctor, it should only be ignored until it is set, or until it is used.
I am quite sure I have seen it (mutability of
Am Thu, 23 May 2013 13:06:44 -0400
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
TDPL 8.4 discusses a raw/cooked model of construction. The same
principle should apply to const/immutable member construction: you get
to cook the field, but you can't taste it while raw.
You are
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Is it possible to change zip filename from
On 5/23/13 2:08 PM, Marco Leise wrote:
Am Thu, 23 May 2013 13:06:44 -0400
schrieb Andrei Alexandrescuseewebsiteforem...@erdani.org:
TDPL 8.4 discusses a raw/cooked model of construction. The same
principle should apply to const/immutable member construction: you get
to cook the field, but you
On Thu, 23 May 2013 23:09:54 +1000
Manu turkey...@gmail.com wrote:
On 23 May 2013 22:56, Max Samukha maxsamu...@gmail.com wrote:
You have module constructors in mixins. How did you solve the
circular imports problem? Banned circular imports?
Pretty much.
I anticipate the problem
On 05/23/13 18:26, Steven Schveighoffer wrote:
On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina art.08...@gmail.com wrote:
If it wasn't clear - it is about the _language_, not what some compiler
currently happens to do. Being able to mutate /initialized/ immutables
is a bad idea. IOW you
On Thu, 23 May 2013 16:42:30 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 05/23/13 18:26, Steven Schveighoffer wrote:
On Thu, 23 May 2013 11:36:00 -0400, Artur Skawina art.08...@gmail.com
wrote:
If it wasn't clear - it is about the _language_, not what some compiler
currently
On Thu, 23 May 2013 17:06:57 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 23 May 2013 16:42:30 -0400, Artur Skawina art.08...@gmail.com
wrote:
For example you couldn't then do this:
struct Packet(uint TY) { /*...*/immutable uint type=TY; immutable ubyte
len=PLen(TY);
On 5/23/2013 4:07 AM, Iain Buclaw wrote:
On 21 May 2013 21:36, Walter Bright newshou...@digitalmars.com wrote:
Join the dmd beta mailing list to keep up with the betas. This one is pretty
much good to go, unless something disastrous crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining
On 5/23/13, Vladimir Panteleev vladi...@thecybershadow.net wrote:
2) it doesn't know which file is the main
program file (the file which must be present for the test script
to succeed), if there is one.
Does https://github.com/D-Programming-Language/dmd/pull/1732 help? It
was merged a while
On Thursday, 23 May 2013 at 12:39:04 UTC, Vladimir Panteleev
wrote:
On Tuesday, 21 May 2013 at 04:52:25 UTC, Diggory wrote:
Either way, at least on windows the separate process would
have to be persistent as creating a new process has a lot more
overhead attached to it than on posix systems.
On 5/23/2013 2:05 AM, Don wrote:
NO NO NO NO. I am violently opposed to this release.
This beta contains the worst language misfeature of all time. It's silently
snuck in under the guise of a bugfix.
Don has an excellent point. His case is bolstered by this causing Tango2 to fail
to compile
On Thu, 23 May 2013 19:03:25 -0400, Artur Skawina art.08...@gmail.com
wrote:
On 05/23/13 23:06, Steven Schveighoffer wrote:
compiles:
struct S
{
const int x;
this(int n)
{
x = n;
}
}
It's the 'const int x = 42;' case we're talking about. *That* one does
not
compile and
On Thu, 23 May 2013 20:01:19 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/23/2013 2:05 AM, Don wrote:
NO NO NO NO. I am violently opposed to this release.
This beta contains the worst language misfeature of all time. It's
silently
snuck in under the guise of a bugfix.
Walter Bright:
Therefore, I propose the following addition of a warning:
--
const int q = 5;
Warning: const field with initializer should be static or enum.
--
Over time, this can be upgraded to a deprecation and then an
error.
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag. The user will be
informed, and the new behavior (which I find useful) is possible.
While that idea has significant merit, I oppose it on the following grounds:
1. It forces a very
On 5/23/13 8:56 PM, Walter Bright wrote:
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag. The
user will be
informed, and the new behavior (which I find useful) is possible.
While that idea has significant merit, I oppose it on
On 5/23/2013 5:56 PM, Walter Bright wrote:
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag. The user will be
informed, and the new behavior (which I find useful) is possible.
While that idea has significant merit, I oppose it on
On 5/23/2013 6:01 PM, Andrei Alexandrescu wrote:
On 5/23/13 8:56 PM, Walter Bright wrote:
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag. The
user will be
informed, and the new behavior (which I find useful) is possible.
While
Walter Bright:
3. Naive users may see their compile fail, see a switch to
'enable' it, and throw the switch. Now it compiles, but fails
silently at runtime. This is because the new behavior is quite
different from the old, and the code that relies on the old
behavior will most likely need to
On 5/23/2013 7:35 PM, bearophile wrote:
Walter Bright:
3. Naive users may see their compile fail, see a switch to 'enable' it, and
throw the switch. Now it compiles, but fails silently at runtime. This is
because the new behavior is quite different from the old, and the code that
relies on the
On 5/23/2013 7:57 PM, bearophile wrote:
Walter Bright:
Even if such naive D programmers exist, maybe it's better to ignore this third
point, because they will not be able to program in D for other reasons.
s/naive/tired/
s/naive/inahurry/
I'm surprised at you, bearophile!
A safe and well
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
On Thu, 23 May 2013 21:56:47 -0400, Walter Bright newshou...@digitalmars.com
wrote:
On 5/23/2013 5:56 PM, Walter Bright wrote:
On 5/23/2013 5:35 PM, Steven Schveighoffer wrote:
What about making it an error UNLESS you pass a compiler flag.
On Friday, 24 May 2013 at 03:38:33 UTC, Walter Bright wrote:
For now, it is the proper path. The warning is that change is
coming, but you have time to fix it.
Yes, with an explanation how to fix it, maybe a link to a webpage
that explain why the change is made, etc . . .
On Thu, 23 May 2013 23:38:32 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
This is one change where ALL code broken by this change
is fixable with a simple solution, and at some point, people will have
to deal
with this.
Yes,
On 5/23/2013 8:53 PM, Steven Schveighoffer wrote:
On Thu, 23 May 2013 23:38:32 -0400, Walter Bright newshou...@digitalmars.com
wrote:
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
This is one change where ALL code broken by this change
is fixable with a simple solution, and at some point,
On 5/23/2013 11:17 PM, Walter Bright wrote:
On 5/23/2013 8:53 PM, Steven Schveighoffer wrote:
On Thu, 23 May 2013 23:38:32 -0400, Walter Bright
newshou...@digitalmars.com
wrote:
On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
This is one change where ALL code broken by this change
is
On 5/22/13 11:16 PM, Jonathan M Davis wrote:
On Thursday, May 23, 2013 02:52:44 Brad Anderson wrote:
Whatever happened to the plan of getting Sönke Ludwig's ddox
generated documentation up on dlang.org?
http://vibed.org/temp/d-programming-language.org/phobos/std/algorithm.html
I see there are
On 2013-05-22 22:33, 1100110 wrote:
Yeah, I was afraid of that...
So, Now the next easiest thing is probably SWIG.
Hey, at least give me a change to fix the problem.
--
/Jacob Carlborg
On 2013-05-22 22:17, nazriel wrote:
I am afraid it doesn't build anymore with DMD git-head.
It isn't dstep itself but one of its dependencies.
I wanted to use it in order to create bindings for XCB but couldn't
built it.
Could you use the pre compiled binary in the mean time:
On 23/05/13 11:23, Adam D. Ruppe wrote:
I've never actually done i18n so I might be full of crap, but I think a
nice way to do it would be something along these lines:
1) (optionally) all printing functions actually take a different type
than just plain string, forcing you to use the
On 2013-05-23 00:17, 1100110 wrote:
hmmm? I never said it was unsuitable, I think you mistaking me for
someone else.
(I also have no experience with libclang, and I'm tired of manually
translating these things... So, am I looking for a way to not translate
this? Yes.)
Also I'm pretty sure
On 2013-05-23 03:01, Ellery Newcomer wrote:
1. D executable, C dll = always worked
2. D executable, D dll, statically loaded = now in 2.063 HEAD
3. D executable, D dll, dynamically loaded (hot swapping) = not yet
4. C executable, D dll = not yet
now? :)
2 works. 4 could possibly work if
On 2013-05-23 01:51, Peter Williams wrote:
That is indeed the case. I avoid all things Apple as my experience has
been that they seem to think they still own a device after they've sold
it to me.
I can understand that. But if we are to create something like this
thread suggest I would say
On 2013-05-23 03:16, Juan Manuel Cabo wrote:
I've been using DWT for some time and it seems stable for me. Thanks to
Jacob Carlborg for maintaining it!
:) Thank you to everyone contributing with pull requests.
--
/Jacob Carlborg
On 2013-05-22 15:52, Walter Bright wrote:
The current beta 4 is pretty much it. Please run DWT for it today and
post any regressions found.
I posted this to the beta mailing list as well:
I get the following error compiling DWT:
static_this without 'this' cannot be shared
This is most
On 2013-05-22 23:15, Andrei Alexandrescu wrote:
I don't understand what you're sustaining. We all want D to become more
stable. It's not a smoke screen or a pretext to reject improvements.
It's a big difference say we want D to _become_ stable and saying D _is_
stable. There are many people
On 2013-05-23 05:15, Jonathan M Davis wrote:
Every time that a library change is introduced it's done in a way that allows
the programmer time to migrate their code. I'm not aware of any case thus far
where we've purposefully changed library code in a manner which immediately
broke user code.
On 2013-05-23 08:27, Peter Williams wrote:
An example of how I would envisage gettext being used in D is:
writefln(gettext(%s: unknown variable at line %s), filename, linenumber);
It is a common practice, to define a macro (or equivalent) _(arg) as an
alias for gettext(arg) (and N_(arg) for
On Thursday, 23 May 2013 at 07:19:46 UTC, Jacob Carlborg wrote:
On 2013-05-23 08:27, Peter Williams wrote:
An example of how I would envisage gettext being used in D is:
writefln(gettext(%s: unknown variable at line %s), filename,
linenumber);
It is a common practice, to define a macro (or
On Thursday, 23 May 2013 at 06:27:28 UTC, Peter Williams wrote:
On 23/05/13 11:23, Adam D. Ruppe wrote:
I've never actually done i18n so I might be full of crap, but
I think a
nice way to do it would be something along these lines:
1) (optionally) all printing functions actually take a
On 2013-05-23 09:29, Diggory wrote:
If you need to change the text then you also need to update the
translations, or at least check that they're still correct, so I see
that as a benefit rather than a problem...
Say I have:
gettext(%s: unknown variable at line %s)
Then I want to change the
On 2013-05-23 10:29, Jacob Carlborg wrote:
Say I have:
gettext(%s: unknown variable at line %s)
Then I want to change the text to:
gettext(%s: not yet known variable at line %s)
I have to find all places where this text is used in the code. Then I
also need to updated the translations. If I
On Thursday, 23 May 2013 at 08:31:46 UTC, Jacob Carlborg wrote:
On 2013-05-23 10:29, Jacob Carlborg wrote:
Say I have:
gettext(%s: unknown variable at line %s)
Then I want to change the text to:
gettext(%s: not yet known variable at line %s)
I have to find all places where this text is
On Thursday, May 23, 2013 09:15:22 Jacob Carlborg wrote:
So, the question is whether it's worth making people change their code
sometime between when we make the change and when std.uni finally goes
away. And I don't think that making people change their code is worth it
regardless of how
On Tuesday, 21 May 2013 at 14:58:56 UTC, Peter Alexander wrote:
On Tuesday, 21 May 2013 at 14:32:46 UTC, Domain wrote:
I vote for std.unicode. Actually, I thought it was std.uri at
the first glance. And I never thought uni is short for unicode.
+1
I wondered what uni meant the first time I
On Monday, May 20, 2013 08:18:12 Jesse Phillips wrote:
If you would like to see the proposed std.uni include into Phobos
please vote yes. If one condition must be met specify under what
condition, otherwise vote no.
Yes.
I wish that I'd managed to review the module more thoroughly before
On Thursday, 23 May 2013 at 01:24:34 UTC, Walter Bright wrote:
And then there are those I don't think we should introduce
breaking changes, and here's my list of must-have features that
break things. :-)
I can't even remember last time when it was the case.
On Wednesday, 22 May 2013 at 23:35:14 UTC, Jesse Phillips wrote:
So while people claim they don't want breaking change, what
they really mean is I only want breaking change when I decide
I to take it. And each person/situation will have different
desire on what they wish to have broken. What
On 2013-05-23 10:45, Diggory wrote:
Given a change that is purely aesthetic like that you could just change
the english translation instead... Also find and replace takes a few
seconds...
If you are suggesting to use a named constant as a key, this also
suffers from the exact problem you are
On Wednesday, 22 May 2013 at 23:52:25 UTC, Jonathan M Davis wrote:
What it comes down to is that breaking changes must provide a
sufficiently high
ROI, or they're unacceptable.
And what was the reason to take this as an axiom? What makes you
think core D developers can decide for all other D
On 2013-05-23 10:49, Jonathan M Davis wrote:
I understand why people want changes like this (and to some extent, I agree),
but I think that if they really wanted them, they should have pushed for them
and created pull requests for them long before now.
I don't see how a pull request will
On 5/23/2013 2:01 AM, Dicebot wrote:
See current beta mailing list for several
examples of what should have never happened in real stable development process.
The reason it is a beta is so we can identify problems and deal with them before
a release.
On Thursday, 23 May 2013 at 09:26:31 UTC, Walter Bright wrote:
On 5/23/2013 2:01 AM, Dicebot wrote:
See current beta mailing list for several
examples of what should have never happened in real stable
development process.
The reason it is a beta is so we can identify problems and deal
with
http://dpaste.dzfl.pl/9172bed3
If mutable keys are allowed in AAs, then why don't they work and why
isn't that documentated? The docs imply this should work, but it
obviously doesn't.
Code:
import std.stdio;
@trusted nothrow void printHash(hash_t h) {
try { writefln(Called hashing
On Thursday, 23 May 2013 at 09:30:51 UTC, David wrote:
...
Problem has been mentioned here :
http://wiki.dlang.org/AA_Implementation_Issues
On Thursday, 23 May 2013 at 09:29:22 UTC, Dicebot wrote:
On Thursday, 23 May 2013 at 09:26:31 UTC, Walter Bright wrote:
On 5/23/2013 2:01 AM, Dicebot wrote:
See current beta mailing list for several
examples of what should have never happened in real stable
development process.
The reason
Am 23.05.2013 11:35, schrieb Dicebot:
On Thursday, 23 May 2013 at 09:30:51 UTC, David wrote:
...
Problem has been mentioned here :
http://wiki.dlang.org/AA_Implementation_Issues
Thanks for the link, but this should be mentioned in the docs, not in
(some) wiki: http://dlang.org/hash-map.html
On 05/23/2013 01:25 AM, Jacob Carlborg wrote:
On 2013-05-23 00:17, 1100110 wrote:
hmmm? I never said it was unsuitable, I think you mistaking me for
someone else.
(I also have no experience with libclang, and I'm tired of manually
translating these things... So, am I looking for a way to
On Thursday, 23 May 2013 at 09:39:18 UTC, Mr. Anonymous wrote:
I think the Development and Release Process wiki page
proposes exactly that.
http://wiki.dlang.org/Release_Process
Yeah, it is how it is usually done and it was proposed numerous
times in various forms. But unless those who
On Thursday, May 23, 2013 11:10:04 Jacob Carlborg wrote:
On 2013-05-23 10:49, Jonathan M Davis wrote:
I understand why people want changes like this (and to some extent, I
agree), but I think that if they really wanted them, they should have
pushed for them and created pull requests for
On 23 May 2013 16:28, Jacob Carlborg d...@me.com wrote:
On 2013-05-23 03:01, Ellery Newcomer wrote:
1. D executable, C dll = always worked
2. D executable, D dll, statically loaded = now in 2.063 HEAD
3. D executable, D dll, dynamically loaded (hot swapping) = not yet
4. C executable, D
On 2013-05-23 12:21, Jonathan M Davis wrote:
Clearly, you don't agree, but we now
have minutes, seconds, etc. as aliases if you don't like dur.
Yeah, that's better.
--
/Jacob Carlborg
On 2013-05-23 12:33, Manu wrote:
Is there an ETA for any any of these? case 3 is of critical
importance... and also 5. C executable, D dll, dynamically loaded (hot
swapping)
I don't know. 5 would probably automatically work if 3 worked, or with
minor modifications. As for the ETA, I don't
1 - 100 of 323 matches
Mail list logo
