On 10/08/2014 10:41 PM, Walter Bright wrote:
On 10/8/2014 6:25 PM, John wrote:
I wish you had some lighting on you. You are hardly visible!
It's to hide the scars where my head was sewed back on.
Getting the brain out was the easy part. The hard part was getting the
brain out! - Hubert
On 08/10/14 22:47, Rainer Schuetze wrote:
C main is no longer under user control, because it is auto-generated
with D main. I never liked that change, we've just discovered another
reason.
All platforms have API's to access the command line arguments passed to
main. On OS X that would be
On 09.10.2014 08:29, Jacob Carlborg wrote:
On 08/10/14 22:47, Rainer Schuetze wrote:
C main is no longer under user control, because it is auto-generated
with D main. I never liked that change, we've just discovered another
reason.
All platforms have API's to access the command line
On 10/8/2014 11:43 PM, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to run code
before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization of a C++ global
could work:
static bool
On 09/10/14 08:43, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to run
code before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization of a C++
global could work:
static bool
On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote:
On 10/8/2014 12:43 AM, Leandro Lucarella wrote:
I think this is an unjustified fear, there are already many
environment
variables that can affect your program. That's why they are
called...
environment variables :)
Being on
On Thursday, 9 October 2014 at 14:20:07 UTC, Sean Kelly wrote:
Back when Druntime was called Ares, it was possible to choose
the GC at link time. Do we really need to defer the decision
to run time? If so, switching GCs after the app has started
should work in most cases, though I'm not sure
On 09.10.2014 10:18, Walter Bright wrote:
On 10/8/2014 11:43 PM, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to
run code
before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization
On 09.10.2014 15:31, Jacob Carlborg wrote:
On 09/10/14 08:43, Rainer Schuetze wrote:
Yes, but the problem is not to access command line arguments, but to run
code before the GC initialization i.e. before _d_run_main is executed.
If we can assume a C++ backend, using static initialization of
On Thursday, 9 October 2014 at 18:33:25 UTC, Rainer Schuetze
wrote:
This is a gcc extension, which isn't supported under Windows by
dmd. Can you add this attribute in GDC/LDC as part of a D file
aswell?
On 2014-10-09 20:33, Rainer Schuetze wrote:
This is a gcc extension, which isn't supported under Windows by dmd.
It seems to be possible in Visual Studio [1], but that still leaves OMF.
[1]
http://stackoverflow.com/questions/1113409/attribute-constructor-equivalent-in-vc
--
/Jacob
On 10/9/2014 7:25 AM, Dicebot wrote:
At the same time I don't see what real benefit such runtime options brings to
the table. This is why in my PR garbage collector is currently chosen during
compilation time.
Choosing at compile time is probably best.
On 10/9/2014 11:25 AM, Rainer Schuetze wrote:
Martin is very much against this, one reason is that it does not work with
druntime in a shared library.
I can understand that, but I also don't know what a reasonable use case would be
for sharing a library yet using different GC's - it sounds
I use d for some time for the job. And it is good. And I want to
use it consistently for the production, but as soon as I started
with the simplest - the connection to the database, I realized
that the language is not yet ready for it. Or suggest the use of
crutches on the forum.
So, there
On Thu, 09 Oct 2014 07:25:19 +
Sergey via Digitalmars-d digitalmars-d@puremagic.com wrote:
So, there are plans to create a native library for connecting to
databases to begin with?
have you tried to read the forums before posting?
signature.asc
Description: PGP signature
On Thu, 09 Oct 2014 07:25:19 +
Sergey via Digitalmars-d digitalmars-d@puremagic.com wrote:
sorry for being rude, i mean that we have mysql-native, for the start.
and we can easily use any C library. i.e. working on native libraries
at least started, and connecting to DB servers is possible.
On Thursday, 9 October 2014 at 07:51:23 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 09 Oct 2014 07:25:19 +
Sergey via Digitalmars-d digitalmars-d@puremagic.com wrote:
sorry for being rude, i mean that we have mysql-native, for the
start.
and we can easily use any C library. i.e. working
I tried this:
http://forum.dlang.org/thread/l403bf$139g$1...@digitalmars.com#post-l4089g:241723:241:40digitalmars.com
but does not work.
On Thursday, 9 October 2014 at 00:13:25 UTC, Andrei Alexandrescu
wrote:
If you love your braces you gotta love your indentation. They
come together... -- Andrei
I guess you're right, but back to the topic.
Has anyone tried something similar for phobos? (I couldn't find
anything)
Does
On Thu, 09 Oct 2014 07:58:24 +
Sergey via Digitalmars-d digitalmars-d@puremagic.com wrote:
But there is no good solution for the production, which need
reliability.
mssql is not a database of choise. ;-) i.e. there aren't alot of people
writing DB frontends in D, and those who writing web
On Wednesday, 8 October 2014 at 19:44:04 UTC, Joakim wrote:
What does this have to D? Well, the phenomenon he describes
probably has a big effect on D's adoption even today, as he was
talking about the spread of programming languages, ones we use
to this day. Certainly worth thinking about,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/14 09:08, ketmar via Digitalmars-d wrote:
On Thu, 09 Oct 2014 07:58:24 + Sergey via Digitalmars-d
digitalmars-d@puremagic.com wrote:
But there is no good solution for the production, which need
reliability.
mssql is not a database
a fascinating one-page read, he predicted that lisp would lose
out to C++ when he delivered this speech in 1990, well worth
Lisp has never been in the same class of languages as C++. Lisp
gained traction in a time period when there were few
alternatives, and it was easy to implement an
On Wednesday, 8 October 2014 at 21:07:24 UTC, Walter Bright wrote:
On 10/6/2014 11:13 AM, Dicebot wrote:
Especially because
you have stated that previous proposal (range-fication) which
did fix the issue
_for me_ is not on the table anymore.
I think it's more stalled because of the
Kenji just proposed a slightly controversial pull request so I want to
reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand side of a
function.
So instead of
const int foo();
you'd should write
int foo() const;
Then at some
On Thu, 09 Oct 2014 10:50:44 +0200
Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote:
Kenji just proposed a slightly controversial pull request so I want
to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand side of a
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I
want to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand
side of a function.
So instead of
const
On Thu, 9 Oct 2014 12:04:36 +0300
ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote:
i mean there were occasional discussions in NG about irritating
'const int bar();' is not 'const(int) bar();' and i've seen nobody
defending prefix attributes. it was either i don't care or it's
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I
want to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand
side of a function.
I'm all for it
Then at
While it would be great if there were a company devoted to such D tooling,
it doesn't exist right now. It is completely unrealistic to expect a D
community of unpaid volunteers to work on these features for your paid
projects. If anybody in the community cared as much about these features as
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I
want to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand
side of a function.
So instead of
const
Am Wed, 08 Oct 2014 13:01:43 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 10/8/14, 1:13 AM, Johannes Pfau wrote:
Code in if(__ctfe) blocks could be (and should be) allowed:
https://github.com/D-Programming-Language/dmd/pull/3572
But if you have got a normal
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I
want to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand
side of a function.
So instead of
const
Am Tue, 07 Oct 2014 15:57:58 +
schrieb Dmitry Olshansky dmitry.o...@gmail.com:
I made a proposal to quantatively measure and tabulate all GC
allocations in Phobos before coming up with solutions to @nogc
Phobos.
After approving node from Andrei I've come up with a piece of
Martin Nowak:
Kenji just proposed a slightly controversial pull request so I
want to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand
side of a function.
So instead of
const int foo();
you'd should write
int foo() const;
Am Thu, 09 Oct 2014 10:50:44 +0200
schrieb Martin Nowak c...@dawg.eu:
Would this affect your code?
Most old code, yes. I used to write all attributes on the left hand
side, but switched to right hand side some time ago.
Do you think it makes your code better or worse?
Probably better,
Am Thu, 9 Oct 2014 12:27:11 +0200
schrieb Johannes Pfau nos...@example.com:
Am Thu, 09 Oct 2014 10:50:44 +0200
schrieb Martin Nowak c...@dawg.eu:
Would this affect your code?
Most old code, yes. I used to write all attributes on the left hand
side, but switched to right hand side some
On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau wrote:
Forgot to some overall I'm for this change. I'd just like some
automated way to fix old code ;-)
I said that I wouldn't write dfix until Walter was willing to
start getting rid of old syntax. Not long after that Walter made
V Thu, 09 Oct 2014 10:50:44 +0200
Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com napsáno:
Kenji just proposed a slightly controversial pull request so I want
to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand side of
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Would this affect your code?
no
Do you think it makes your code better or worse?
no change, my code already looks like that
Is this just a pointless style change?
no, left hand side function qualifier is just wrong IMO.
On 10/09/2014 01:10 PM, Brian Schott wrote:
dfix is under development. You can find it here:
https://github.com/Hackerpilot/dfix
That would make such decisions much easier :).
It doesn't appear to rewrite AST but only tokens at the moment.
How reliable is it?
On Thursday, 9 October 2014 at 11:24:08 UTC, Robert burner
Schadek wrote:
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak
wrote:
Would this affect your code?
no
Do you think it makes your code better or worse?
no change, my code already looks like that
Is this just a pointless
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Would this affect your code?
I've written code before in the style:
@property pure nothrow const //- HERE
int foo();
So anybody else using this style might be affected.
But even then, I agree. D has always been about if it's
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Would this affect your code?
No, I always wrote it on the right.
Do you think it makes your code better or worse?
Better.
Is this just a pointless style change?
No, removing confusing style is good.
Please test your work with (at least) a few different D compiler
versions.
There have been some recent changes that cause somewhat trivial
incompatibilities between compiler versions, which can be almost
entirely avoided with some care.
A few simple simple considerations to help your code
This pull request is a good thing (TM). +1 all the way.
Atila
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I
want to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers
Debugging, ldc (for windows), and editor integrations (auto
complete,
navigation, refactoring tools) are my impersonal (and hopefully
non-controversial) short list. They trump everything else I've
I don't know how well DCD works with other editors, but in Emacs
at least (when DCD doesn't
Dne 9.10.2014 v 10:50 Martin Nowak via Digitalmars-d napsal(a):
Would this affect your code?
yes, but I understand the rationale so I don't mind
Do you think it makes your code better or worse?
less ambiguous, so I would say better
Is this just a pointless style change?
no
--
Martin
On 09/10/2014 10:15 pm, Atila Neves via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Debugging, ldc (for windows), and editor integrations (auto complete,
navigation, refactoring tools) are my impersonal (and hopefully
non-controversial) short list. They trump everything else I've
I
On Wednesday, 8 October 2014 at 03:20:21 UTC, Walter Bright wrote:
Can we at least agree that Dicebot's request for having the
behaviour of
inadvisable constructs defined such that an implementation
cannot randomly
change behaviour and then have the developers close down the
corresponding
On Thursday, 9 October 2014 at 07:25:21 UTC, Sergey wrote:
So, there are plans to create a native library for connecting
to databases to begin with?
To put it shortly - very unlikely. Well, unless you do it
yourself, of course, and contribute to the community :) It has a
very small
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I
want to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand
side of a function.
So instead of
const
On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu
wrote:
On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via
Digitalmars-d wrote:
On Monday, 6 October 2014 at 16:06:04 UTC, Andrei
Alexandrescu wrote:
[...]
It would be
On 10/9/14 4:50 AM, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I want to
reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand side of a
function.
So instead of
const int foo();
you'd should
On Wednesday, 8 October 2014 at 20:07:09 UTC, Walter Bright wrote:
On 10/8/2014 4:17 AM, Don wrote:
As I said in my Dconf 2013 talk -- I advocate a focus on
Return On Investment.
I'd love to see us chasing the easy wins.
I love the easy wins, too. It'd be great if you'd start a
thread about
On Thursday, 9 October 2014 at 09:37:29 UTC, Danni Coy via
Digitalmars-d wrote:
It might be unfair but it is still a massive problem. The
tooling
compared to what I have with say C++ and Qt is not a fun
experience.
The language is nicer but the difference in tooling is making
the
difference
Dicebot wrote:
Switch to input/output ranges as API fundamentals was supposed
to fix it. Custom management policies as you propose won't fix
it at all because garbage will still be there, simply managed
in a different way.
Would it be impractical to support multiple approaches through
On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote:
Dicebot wrote:
Switch to input/output ranges as API fundamentals was supposed
to fix it. Custom management policies as you propose won't fix
it at all because garbage will still be there, simply managed
in a different way.
Would it
On Thursday, 9 October 2014 at 14:47:00 UTC, Dicebot wrote:
On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote:
Dicebot wrote:
Switch to input/output ranges as API fundamentals was
supposed to fix it. Custom management policies as you propose
won't fix it at all because garbage will
2014-10-09 23:17 GMT+09:00 Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com:
Just one point to make, this will still work, right?:
const {
int foo();
}
const:
int foo();
My PR still allows those block or label style attributes.
Kenji Hara
On 10/9/14, 1:01 AM, Robert burner Schadek wrote:
On Thursday, 9 October 2014 at 00:13:25 UTC, Andrei Alexandrescu wrote:
If you love your braces you gotta love your indentation. They come
together... -- Andrei
I guess you're right, but back to the topic.
Has anyone tried something similar
Manu via Digitalmars-d digitalmars-d@puremagic.com wrote in message
news:mailman.559.1412859804.9932.digitalmar...@puremagic.com...
Dan Murphy seemed to think ddmd would have some focus on usage as a lib?
Yes, but it's a long way off.
On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
Multiple approaches to how library functions can handle memory.
As long as it allows us avoid creating new GC roots and keep
using GC for all allocations at the same time.
On 10/9/14, 7:09 AM, Dicebot wrote:
Yes and this is exactly why I am that concerned about recent memory
management policy thread. Don has already stated it in his talks but I
will repeat important points:
1) We don't try to avoid GC in any way
2) However it is critical for performance to avoid
If there is a C library for MSSQL you should be able to use that
from your D code. If you do, it would be handy for others if you
could publish any bindings you create as a dub package
(code.dlang.org).
Dicebot pub...@dicebot.lv wrote:
On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
Multiple approaches to how library functions can handle memory.
As long as it allows us avoid creating new GC roots and keep using GC for
all allocations at the same time.
To clarify: calling GC.free
On Thursday, 9 October 2014 at 15:32:06 UTC, Andrei Alexandrescu
wrote:
On 10/9/14, 7:09 AM, Dicebot wrote:
Yes and this is exactly why I am that concerned about recent
memory
management policy thread. Don has already stated it in his
talks but I
will repeat important points:
1) We don't try
On Thursday, 9 October 2014 at 15:59:12 UTC, Andrei Alexandrescu
wrote:
Dicebot pub...@dicebot.lv wrote:
On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
Multiple approaches to how library functions can handle
memory.
As long as it allows us avoid creating new GC roots and keep
Hi,
I just stubmled over an enhancement in object_.d and object.di
Benjamin Thaut described on his page:
http://3d.benjamin-thaut.de/?p=25#more-25.
The enhancement looks quite good and handy for me and would be a
quick win to have some more runtime type information in the
language.
Does
It's a clean break and easy to fix, and eliminated a confusing
ambiguity. I'm all for it.
On 10/9/14, 9:00 AM, Dicebot wrote:
On Thursday, 9 October 2014 at 15:59:12 UTC, Andrei Alexandrescu wrote:
Dicebot pub...@dicebot.lv wrote:
On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
Multiple approaches to how library functions can handle memory.
As long as it allows us avoid
Am Thu, 09 Oct 2014 15:57:15 +
schrieb Dicebot pub...@dicebot.lv:
Unfortunately it doesn't. RC does. Lazy computation relies on
escaping ranges all over the place (i.e. as fields inside
structs implementing the lazy computation). If there's no way
to track those many tidbits,
Am Thu, 09 Oct 2014 13:10:34 +
schrieb Dicebot pub...@dicebot.lv:
On Wednesday, 8 October 2014 at 03:20:21 UTC, Walter Bright wrote:
Can we at least agree that Dicebot's request for having the
behaviour of
inadvisable constructs defined such that an implementation
cannot randomly
Am Thu, 09 Oct 2014 08:11:33 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 10/9/14, 1:01 AM, Robert burner Schadek wrote:
On Thursday, 9 October 2014 at 00:13:25 UTC, Andrei Alexandrescu
wrote:
If you love your braces you gotta love your indentation. They come
On 9 October 2014 17:33, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Thu, 09 Oct 2014 13:10:34 +
schrieb Dicebot pub...@dicebot.lv:
On Wednesday, 8 October 2014 at 03:20:21 UTC, Walter Bright wrote:
Can we at least agree that Dicebot's request for having the
On 10/9/14, 9:36 AM, Johannes Pfau wrote:
Am Thu, 09 Oct 2014 08:11:33 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 10/9/14, 1:01 AM, Robert burner Schadek wrote:
On Thursday, 9 October 2014 at 00:13:25 UTC, Andrei Alexandrescu
wrote:
If you love your braces you gotta
On 10/9/14, 8:57 AM, Dicebot wrote:
On Thursday, 9 October 2014 at 15:32:06 UTC, Andrei Alexandrescu wrote:
Unfortunately it doesn't. RC does. Lazy computation relies on escaping
ranges all over the place (i.e. as fields inside structs implementing
the lazy computation). If there's no way to
On 10/9/14, 9:27 AM, Johannes Pfau wrote:
Am Thu, 09 Oct 2014 15:57:15 +
schrieb Dicebot pub...@dicebot.lv:
Unfortunately it doesn't. RC does. Lazy computation relies on
escaping ranges all over the place (i.e. as fields inside
structs implementing the lazy computation). If there's no way
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I
want to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand
side of a function.
+1.
Prefixed const is
On Thursday, 9 October 2014 at 16:36:35 UTC, Johannes Pfau wrote:
+1, std.benchmark should be revived.
-1, This really does not solve my problem. I need a parameterized
unit test facility aka. Haskell QuickCheck with the additional
benchmarking feature that allows me/us to track performance
Am 09.10.2014 um 10:24 schrieb Russel Winder via Digitalmars-d:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/14 09:08, ketmar via Digitalmars-d wrote:
On Thu, 09 Oct 2014 07:58:24 + Sergey via Digitalmars-d
digitalmars-d@puremagic.com wrote:
But there is no good solution for
On Thursday, 9 October 2014 at 11:10:47 UTC, Brian Schott wrote:
On Thursday, 9 October 2014 at 10:29:46 UTC, Johannes Pfau
wrote:
Forgot to some overall I'm for this change. I'd just like some
automated way to fix old code ;-)
I said that I wouldn't write dfix until Walter was willing to
On Thursday, 9 October 2014 at 17:11:57 UTC, Paulo Pinto wrote:
Really? I am yet to do any project with it instead of MySQL.
--
Paulo
All I know is that in Arch Linux MySQL is not even in official
repos anymore, only MariaDB is there :)
On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei Alexandrescu
wrote:
To clarify: calling GC.free does remove the root, correct?
Not before it creates one. When I mean avoid creating new GC
roots I
mean no GC activity at all other than extending existing
chunks
That's interesting. So
On Thursday, 9 October 2014 at 16:33:53 UTC, Johannes Pfau wrote:
I think Walter sometimes suggested that it would be valid for a
compiler to not unwind Errors at all (in release mode), but
simply kill
the program and dump a error message. This would finally allow
us to
optimize nothrow
On Thursday, 9 October 2014 at 16:41:22 UTC, Andrei Alexandrescu
wrote:
Usage of output range is simply a generalization of out array
parameter
used in both Tango and our code. It is _already_ proved to
work for our
cases.
Got it. Output ranges work great with unstructured/linear
outputs -
I get the bracing point, but how does this translate to my unit
testing (quickcheck) problem?
On 10/9/14, 9:57 AM, Robert burner Schadek wrote:
On Thursday, 9 October 2014 at 16:36:35 UTC, Johannes Pfau wrote:
+1, std.benchmark should be revived.
-1, This really does not solve my problem. I need a parameterized unit
test facility aka. Haskell QuickCheck with the additional
On Thursday, 9 October 2014 at 11:31:01 UTC, Martin Nowak wrote:
It doesn't appear to rewrite AST but only tokens at the moment.
The features that are implemented so far don't need the AST.
Others such as the function attributes and C-style arrays will
need help from the parser.
How
On Thursday, 9 October 2014 at 17:11:57 UTC, Paulo Pinto wrote:
Am 09.10.2014 um 10:24 schrieb Russel Winder via Digitalmars-d:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/10/14 09:08, ketmar via Digitalmars-d wrote:
On Thu, 09 Oct 2014 07:58:24 + Sergey via Digitalmars-d
On Thursday, October 09, 2014 10:50:44 Martin Nowak via Digitalmars-d wrote:
Kenji just proposed a slightly controversial pull request so I want to
reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand side of a
function.
So instead
On Thursday, 9 October 2014 at 17:31:32 UTC, Dicebot wrote:
On Thursday, 9 October 2014 at 16:33:53 UTC, Johannes Pfau
wrote:
I think Walter sometimes suggested that it would be valid for a
compiler to not unwind Errors at all (in release mode), but
simply kill
the program and dump a error
Am 09.10.2014 um 19:23 schrieb Dicebot:
On Thursday, 9 October 2014 at 17:11:57 UTC, Paulo Pinto wrote:
Really? I am yet to do any project with it instead of MySQL.
--
Paulo
All I know is that in Arch Linux MySQL is not even in official repos
anymore, only MariaDB is there :)
The
On Thursday, 9 October 2014 at 18:36:10 UTC, Paulo Pinto wrote:
Am 09.10.2014 um 19:23 schrieb Dicebot:
All I know is that in Arch Linux MySQL is not even in official
repos
anymore, only MariaDB is there :)
The Enterprise only knows RedHat, SuSE and Ubuntu as GNU/Linux
distributions. :)
On Thursday, 9 October 2014 at 18:32:55 UTC, Marc Schütz wrote:
Can it simply skip unwinding up to the next not-nothrow
function? I.e. destructors of objects (and finally/scope(exit))
inside `nothrow` functions will not be executed, but unwinding
will continue as normal at the first function
On 10/09/2014 02:47 PM, Dicebot wrote:
On Thursday, 9 October 2014 at 18:36:10 UTC, Paulo Pinto wrote:
Am 09.10.2014 um 19:23 schrieb Dicebot:
All I know is that in Arch Linux MySQL is not even in official repos
anymore, only MariaDB is there :)
The Enterprise only knows RedHat, SuSE and
On 09/25/2014 02:49 PM, H. S. Teoh via Digitalmars-d wrote:
Make-heads find the idea of the compiler being part of the input to a
build rule strange; to me, it's common sense.
Yes. This is exactly why (unless it's been reverted or regressed? I only
mention that because I haven't looked
On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:
Kenji just proposed a slightly controversial pull request so I
want to reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand
side of a function.
Great. I support this.
Would this affect your code?
No, but is it fixed on the ddoc side? The last ddoc I generated had function
attributes first, even though in the code they were on the right. It would be
pretty awful to have function attributes obliged to be on the right in code, but
still appearing on the
On 09/10/14 13:38, monarch_dodra via Digitalmars-d wrote:
I'm not really sure about the: Then at some future point we could apply the
left hand side qualifiers to the return type, e.g. `const int foo();` ==
`const(int) foo();`
I don't think it buys us anything, except maybe silently changing
1 - 100 of 184 matches
Mail list logo
