On 2/4/15 11:48 PM, Foo wrote:
I would be glad if you or Walter could review the other parts as well.
I'm very sure that your review will be very helpful and I'm convinced
that the modules Array or Smart Pointer could be useful for phobos.
Your code is a ways from being in reviewable form. It w
On Thursday, 5 February 2015 at 07:28:36 UTC, Paulo Pinto wrote:
I miss the point about in.
DbC as presentend by Eiffel and adopted in .NET, Ada among
others, the complete contract is on the callee.
It doesn't make sense otherwise.
Conceptually the precondition is a specification that the
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 9:13 AM, Foo wrote:
For what it's worth, today I finished the current work. Now we
will
start working with it. If someone has critique, improvement
suggestions
or want to take some ideas, he is free to do so.
T
On Thursday, 5 February 2015 at 06:15:39 UTC, H. S. Teoh wrote:
On Thu, Feb 05, 2015 at 05:42:57AM +, Meta via
Digitalmars-d wrote:
[...]
I don't know about others (besides Beatophile, who religiously
adheres
to writing contacts), but putting contracts on functions is a
hassle.
I never do
On Thursday, 5 February 2015 at 06:46:12 UTC, weaselcat wrote:
After reading this thread I think I'm the only person here who
actually likes makefiles.
Nothing ever feels as complete as a good old hand written
makefile.
As long as you just need one compiler, one OS, one CPU
architecture and
On 2/4/15 10:46 PM, weaselcat wrote:
After reading this thread I think I'm the only person here who actually
likes makefiles.
Nothing ever feels as complete as a good old hand written makefile.
I'm don't mind makefiles. That says, our dmd/druntime/phobos/dlang.org
makefiles break at the drop
On 2/4/15 10:23 PM, Jakob Ovrum wrote:
On Thursday, 5 February 2015 at 06:18:07 UTC, BlackEdder wrote:
On Thursday, 5 February 2015 at 06:03:38 UTC, Jakob Ovrum wrote:
On Thursday, 5 February 2015 at 01:10:18 UTC, Andrei Alexandrescu wrote:
On 2/4/15 5:06 PM, Matt Kline wrote:
Is there a JSON
On Thursday, 5 February 2015 at 04:36:39 UTC, Zach the Mystic
wrote:
I have an idea. Treat all assert statements which come before
the first non-assert statement as part of the 'in' contract.
I'm not saying the compiler has to generate a whole 'in'
function, but these asserts can be internally
On Thursday, 5 February 2015 at 06:51:35 UTC, Vlad Levenfeld
wrote:
I could care less
Er, stupid but unfortunately common american english idiom. For
non-native speakers, I mean to say I could NOT care less.
You have clearly put a lot of effort in this. That makes me very
uneasy to repeat the same critique as earlier but, sadly, it
still all applies. This proposal tries to fix problems it doesn't
prove exist, doing so with solutions that are not guranteed to
help.
It also wrongly explains current
On Thursday, 5 February 2015 at 06:26:17 UTC, Meta wrote:
I've found that the more years of experience I have under my
belt, the less documentation I wrote. When I was starting out I
was very diligent in doing everything the Correct Way so as to
cultivate good habits. I'd find my regression ove
After reading this thread I think I'm the only person here who
actually likes makefiles.
Nothing ever feels as complete as a good old hand written
makefile.
On Thursday, 5 February 2015 at 05:51:18 UTC, tcak wrote:
On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:
On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler
wrote:
This looks very similar to std.experimental. I originally
thought that the difference between std.expe
"Meta" wrote in message news:ejqtxksoifmqzetll...@forum.dlang.org...
I don't know about others (besides Beatophile, who religiously adheres to
writing contacts), but putting contracts on functions is a hassle. I never
do it unless I'm feeling particularly full of divine fervor. It's a lot
lik
On Thursday, 5 February 2015 at 06:15:39 UTC, H. S. Teoh wrote:
On Thu, Feb 05, 2015 at 05:42:57AM +, Meta via
Digitalmars-d wrote:
[...]
I don't know about others (besides Beatophile, who religiously
adheres
to writing contacts), but putting contracts on functions is a
hassle.
I never do
On Thursday, 5 February 2015 at 06:18:07 UTC, BlackEdder wrote:
On Thursday, 5 February 2015 at 06:03:38 UTC, Jakob Ovrum wrote:
On Thursday, 5 February 2015 at 01:10:18 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 5:06 PM, Matt Kline wrote:
Is there a JSON library that most other people are using
On Thursday, 5 February 2015 at 06:03:38 UTC, Jakob Ovrum wrote:
On Thursday, 5 February 2015 at 01:10:18 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 5:06 PM, Matt Kline wrote:
Is there a JSON library that most other people are using
instead?
http://vibed.org has a good one. -- Andrei
http://
On Wednesday, 4 February 2015 at 16:46:19 UTC, Andrei
Alexandrescu wrote:
On 2/1/15 8:00 PM, Vadim Lopatin wrote:
I would like to propose Java way for implementation of DB
access (JDBC -
Java DataBase Connectors).
[snip]
I think we should use ODBC as the foundation and build neat
D-ish stuff
On Thu, Feb 05, 2015 at 05:42:57AM +, Meta via Digitalmars-d wrote:
[...]
> I don't know about others (besides Beatophile, who religiously adheres
> to writing contacts), but putting contracts on functions is a hassle.
> I never do it unless I'm feeling particularly full of divine fervor.
> It'
On Tuesday, 3 February 2015 at 22:13:50 UTC, Chris wrote:
On Wednesday, 28 January 2015 at 15:54:31 UTC, anonymous wrote:
On Tuesday, 27 January 2015 at 20:02:12 UTC, anonymous wrote:
PR:
https://github.com/D-Programming-Language/dlang.org/pull/869
- For details see here.
Live version: http://
On Thursday, 5 February 2015 at 01:10:18 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 5:06 PM, Matt Kline wrote:
Is there a JSON library that most other people are using
instead?
http://vibed.org has a good one. -- Andrei
http://code.dlang.org/packages/std_data_json
On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:
On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler
wrote:
This looks very similar to std.experimental. I originally
thought that the difference between std.experimental and this
library was going to be how it was used.
On Thursday, 5 February 2015 at 01:06:57 UTC, Matt Kline wrote:
I'm trying to build a small utility for a project at work that
stores some config on-disk as JSON. Imagine my dismay when I
find that opIndexAssign hasn't been added to JSONValue until
after 2.066 went out:
https://github.com/D-Pr
Zach the Mystic:
I have an idea. Treat all assert statements which come before
the first non-assert statement as part of the 'in' contract.
I'm not saying the compiler has to generate a whole 'in'
function, but these asserts can be internally tagged to behave
*as if* in an 'in' contract. That
On Thursday, 5 February 2015 at 01:33:54 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 5:32 PM, deadalnix wrote:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei
Alexandrescu wrote:
Yah, I agree "in" is useful for overridable functions. In
fact I'd say
it's useful _only_ for overridable functi
On Wednesday, 4 February 2015 at 19:04:52 UTC, Jacob Carlborg
wrote:
On 2015-02-02 11:13, Vladimir Panteleev wrote:
As I said in my reply to Mathias, what dub does breaks the
module path
and file path consistency when modules/subpackages lie in the
repository
root.
So it's the default behav
On Thursday, 5 February 2015 at 00:01:00 UTC, Andrei Alexandrescu
wrote:
I have a practical matter - looking at
https://github.com/D-Programming-Language/phobos/commits/master/std/file.d
I can see the commits but not the pull requests they correspond
to. Is there an easy way to see them?
If y
On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler
wrote:
This looks very similar to std.experimental. I originally
thought that the difference between std.experimental and this
library was going to be how it was used.
std.experimental:
module that may become part of the standa
On Thursday, 5 February 2015 at 00:43:04 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 4:37 PM, Adam D. Ruppe wrote:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the
function
signature. Contracts should be encouraged and increa
On Saturday, 31 January 2015 at 09:14:14 UTC, Martin Nowak wrote:
Can we commit to having stuff done by Feb 15 for a release on
Mar 1? -- Andrei
Sounds good, work on regressions should start soon and we
should no longer add features.
Martin
Can you take a look at
https://issues.dlang.org/s
On Wednesday, 4 February 2015 at 22:41:29 UTC, deadalnix wrote:
On Wednesday, 4 February 2015 at 22:09:04 UTC, Nordlöw wrote:
On Wednesday, 4 February 2015 at 21:45:02 UTC, deadalnix wrote:
On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote:
Can we please change the file extensions in DM
On 2/2/15 2:42 PM, "Ulrich =?UTF-8?B?S8O8dHRsZXIi?=
" wrote:
On Friday, 30 January 2015 at 23:17:09 UTC, Andrei Alexandrescu wrote:
Sorry, I thought that was in the bag. Keep current semantics, call it
chunkBy. Add the key to each group when the predicate is unary. Make
sure aggregate() works ni
On 2/4/15 6:10 PM, Jonathan Marler wrote:
On Thursday, 5 February 2015 at 01:53:17 UTC, H. S. Teoh wrote:
It's an example of blindly adhering to the letter of the rule while
violating the spirit of the rule, which is to make code more readable.
T
Ahhh...thanks for this. I've been searching
On Thursday, 5 February 2015 at 01:53:17 UTC, H. S. Teoh wrote:
It's an example of blindly adhering to the letter of the rule
while
violating the spirit of the rule, which is to make code more
readable.
T
Ahhh...thanks for this. I've been searching for an eloquent way
to say this for a wh
On 2/4/15 5:34 PM, deadalnix wrote:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
Would introduce an exception to our brace-on-its-line rule.
Will I start the next world war if I mention this rule is only useful to
eat vertical space on my screen (especially when us
On Thu, Feb 05, 2015 at 01:34:47AM +, deadalnix via Digitalmars-d wrote:
> On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
> >Would introduce an exception to our brace-on-its-line rule.
Which is already blatantly violated everywhere in single-line functions.
> Will I
On 2/4/15 5:32 PM, deadalnix wrote:
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote:
Yah, I agree "in" is useful for overridable functions. In fact I'd say
it's useful _only_ for overridable functions.
Putting the contract in the caller is not only useful for overridab
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu
wrote:
Yah, I agree "in" is useful for overridable functions. In fact
I'd say it's useful _only_ for overridable functions.
Putting the contract in the caller is not only useful for
overridable functions.
1/ If a lib is comp
On Thursday, 5 February 2015 at 01:09:15 UTC, Andrei Alexandrescu
wrote:
Non-debug mode removes asserts statically. -- Andrei
Using pre-/post-conditions allows the _caller_ to specify whether
the checks are run without recompiling the function body, at
least in theory.
David
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu
wrote:
Would introduce an exception to our brace-on-its-line rule.
Will I start the next world war if I mention this rule is only
useful to eat vertical space on my screen (especially when using
contracts) ?
On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 4:47 PM, deadalnix wrote:
1/ the initial is overly long because the styling is wasteful.
void foo() in {
...
} body {
...
}
Is simply one line more than not using contracts.
Would introduce an exception to
On 2/4/15 5:06 PM, Matt Kline wrote:
Is there a JSON library that most other people are using instead?
http://vibed.org has a good one. -- Andrei
On 2/4/15 4:47 PM, deadalnix wrote:
1/ the initial is overly long because the styling is wasteful.
void foo() in {
...
} body {
...
}
Is simply one line more than not using contracts.
Would introduce an exception to our brace-on-its-line rule.
I need to take issue with "that code is no
I'm trying to build a small utility for a project at work that
stores some config on-disk as JSON. Imagine my dismay when I find
that opIndexAssign hasn't been added to JSONValue until after
2.066 went out:
https://github.com/D-Programming-Language/phobos/pull/2607
1. Is there any way until 2.
On 2/4/15 4:50 PM, Jonathan Marler wrote:
On Thursday, 5 February 2015 at 00:42:01 UTC, Andrei Alexandrescu wrote:
On 2/4/15 4:40 PM, Jonathan Marler wrote:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the function
signatu
On Thursday, 5 February 2015 at 00:42:01 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 4:40 PM, Jonathan Marler wrote:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the
function
signature. Contracts should be encouraged and incr
On Thursday, 5 February 2015 at 00:43:04 UTC, Andrei Alexandrescu
wrote:
Yah I concede this is a good point. Yet we're looking at an
actual liability and are supposed to look at some vague
possible future benefit. -- Andrei
There only a benefit because the coding style for contract is
ridicul
On Wed, Feb 04, 2015 at 04:24:14PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> I'm seeing another idiom that seems to become fashionable. Consider this
> excerpt from
> https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:
>
> auto opS
On Thursday, 5 February 2015 at 00:42:01 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 4:40 PM, Jonathan Marler wrote:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the
function
signature. Contracts should be encouraged and incr
On Thursday, 5 February 2015 at 00:24:15 UTC, Andrei Alexandrescu
wrote:
I'm seeing another idiom that seems to become fashionable.
Consider this excerpt from
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:
auto opSlice(size_t low, size_
On 2/4/15 4:37 PM, Adam D. Ruppe wrote:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the function
signature. Contracts should be encouraged and increased, not discouraged.
I agree. Moreover, if the assert fails in the con
On 2/4/15 4:35 PM, bearophile wrote:
Contracts can be read by tools, and they are part of the function
signature.
The signature part matters only for overridable functions. I agree the
part about tooling has merit. -- Andrei
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the
function signature. Contracts should be encouraged and
increased, not discouraged.
Bye,
bearophile
Not to mention that contracts can be removed by the compiler at
compile
On 2/4/15 4:40 PM, Jonathan Marler wrote:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the function
signature. Contracts should be encouraged and increased, not discouraged.
Bye,
bearophile
Not to mention that contracts c
On 2/4/15 4:30 PM, Rikki Cattermole wrote:
So are we recommending against contract based programming for simple
getter type methods?
The shorter version is as contract based as the other.
Personally I think those auto's are more important to get rid of in this
code. They actually do harm for
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Andrei Alexandrescu:
auto opSlice(size_t low, size_t high)
in
{
assert(low <= high);
}
body
{
import std.range : take;
r
Andrei Alexandrescu:
auto opSlice(size_t low, size_t high)
in
{
assert(low <= high);
}
body
{
import std.range : take;
return this[low .. $].take(high - low);
}
wh
Andrei Alexandrescu:
http://wiki.dlang.org/DIP25
I'd like a more comprehensive and flexible solution to the
problem of static memory ownership.
Bye,
bearophile
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the
function signature. Contracts should be encouraged and
increased, not discouraged.
I agree. Moreover, if the assert fails in the contract, in
theory, we can point the erro
On 5/02/2015 1:24 p.m., Andrei Alexandrescu wrote:
I'm seeing another idiom that seems to become fashionable. Consider this
excerpt from
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:
auto opSlice(size_t low, size_t high)
i
I'm seeing another idiom that seems to become fashionable. Consider this
excerpt from
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/iteration.d#L407:
auto opSlice(size_t low, size_t high)
in
{
assert(low <= high);
http://wiki.dlang.org/DIP25
Andrei
On Wed, Feb 04, 2015 at 04:00:59PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
> I have a practical matter - looking at
> https://github.com/D-Programming-Language/phobos/commits/master/std/file.d I
> can see the commits but not the pull requests they correspond to. Is
> there an eas
On 2/4/15 3:46 PM, Jonathan Marler wrote:
On Wednesday, 4 February 2015 at 23:01:48 UTC, Andrei Alexandrescu wrote:
Also I'd like to open discussion with the dlang brass to figure out
ways on how to make sure this doesn't happen again in the future.
Thanks,
Andrei
Find out who approved the
On Wednesday, 4 February 2015 at 23:01:48 UTC, Andrei
Alexandrescu wrote:
Also I'd like to open discussion with the dlang brass to figure
out ways on how to make sure this doesn't happen again in the
future.
Thanks,
Andrei
Find out who approved the PRs. Maybe an approver needs to be
remo
On 2/4/15 3:09 PM, Foo wrote:
Did you take a deeper look after I grumbled about it? :P
That's exactly right. I was like, "let me show a shiny good example of
how things are done, how wonderful D is, how..." urgh. -- Andrei
On Wed, Feb 04, 2015 at 03:01:47PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> I just stepped into a disaster zone in std.file and submitted
> https://issues.dlang.org/show_bug.cgi?id=14125.
>
> This reveals the merits of reviewing pull requests carefully, and the
> issues that can crop
On Wednesday, 4 February 2015 at 23:01:48 UTC, Andrei
Alexandrescu wrote:
I just stepped into a disaster zone in std.file and submitted
https://issues.dlang.org/show_bug.cgi?id=14125.
This reveals the merits of reviewing pull requests carefully,
and the issues that can crop in when that doesn'
On Wednesday, 4 February 2015 at 22:10:51 UTC, Piotrek wrote:
Hi,
Abstract:
D Drafting Library is an official library modeled by the D
community and designed to support the development process of
the D Standard Library. The drafting library is coupled with
the standard library and doesn't in
On 2/4/2015 1:24 PM, Dicebot wrote:
On Wednesday, 4 February 2015 at 21:16:15 UTC, Nordlöw wrote:
BTW: I still can't the debugger to find source information.
How and where do I the debug build configuration to call make with
ENABLE_DEBUG=1
as argument?
I tend to simply edit posix.mak and cha
On Wednesday, 4 February 2015 at 23:01:48 UTC, Andrei
Alexandrescu wrote:
I just stepped into a disaster zone in std.file and submitted
https://issues.dlang.org/show_bug.cgi?id=14125.
This reveals the merits of reviewing pull requests carefully,
and the issues that can crop in when that doesn'
I just stepped into a disaster zone in std.file and submitted
https://issues.dlang.org/show_bug.cgi?id=14125.
This reveals the merits of reviewing pull requests carefully, and the
issues that can crop in when that doesn't happen.
I appeal again to a broader participation to reviewing pull req
On Wednesday, 4 February 2015 at 21:51:55 UTC, AndyC wrote:
The vision says "We aim to make the standard library usable in
its entirety without a garbage collector. Safe code should not
require the presence of a garbage collector"
I was just playing with std.json, and this part got me to
thin
On 2/4/2015 12:46 PM, Zach the Mystic wrote:
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's w
On Wednesday, 4 February 2015 at 22:09:04 UTC, Nordlöw wrote:
On Wednesday, 4 February 2015 at 21:45:02 UTC, deadalnix wrote:
On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote:
Can we please change the file extensions in DMD from .c to
.cpp for C++ sources?
If I make a PR to make thes
Hi,
Abstract:
D Drafting Library is an official library modeled by the D
community and designed to support the development process of the
D Standard Library. The drafting library is coupled with the
standard library and doesn't introduce any duplicated
functionality. It should be used during
On 2/4/15 12:08 PM, Walter Bright wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear.
Please nail it down in t
On 2/4/15 1:51 PM, AndyC wrote:
How will we parse a string into a json struct w/out allocating memory?
It will allocate, but without creating garbage. Reference counted
strings are the answer. -- Andrei
On Wednesday, 4 February 2015 at 21:45:02 UTC, deadalnix wrote:
On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote:
Can we please change the file extensions in DMD from .c to
.cpp for C++ sources?
If I make a PR to make these file cpp, what are the chances for
it to be accepted ? git i
On 2/5/2015 4:02 AM, Jacob Carlborg wrote:
On 2015-02-02 09:58, Joseph Rushton Wakeling via Digitalmars-d wrote:
Scenario: a dependency has a security hole that gets patched. If the
dub package is updated, all applications using that dub package will
automatically have that update available ne
To Zachary:
"The big temptation for software developers is to *promise*
stability in order to attract the users they need in order to get
the feedback they need in order to create the best possible
design, and then break stability with the new design."
Yes - economists call this time inconsisten
The vision says "We aim to make the standard library usable in
its entirety without a garbage collector. Safe code should not
require the presence of a garbage collector"
I was just playing with std.json, and this part got me to
thinking. How will we parse a string into a json struct w/out
a
On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote:
Can we please change the file extensions in DMD from .c to .cpp
for C++ sources?
If I make a PR to make these file cpp, what are the chances for
it to be accepted ? git is capable of tracking renaming, so it
should create any conflict
On Wednesday, 4 February 2015 at 20:55:59 UTC, Walter Bright
wrote:
On 2/4/2015 12:42 PM, Foo wrote:
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
@trusted
@nogc
char[] read(const string filename) nothrow {
Yes that is correct, currently there is no error checking,
On Wednesday, 4 February 2015 at 20:55:59 UTC, Walter Bright
wrote:
On 2/4/2015 12:42 PM, Foo wrote:
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
@trusted
@nogc
char[] read(const string filename) nothrow {
Yes that is correct, currently there is no error checking,
Absolutely not inappropriate. I actually prefer it being a
newsgroup user. Many people will instead reference a post on
the forum instead of replying, and then I have to use the forum
interface to see what they are talking about. I'd much rather
have the full discussion in my preferred interf
On Wednesday, 4 February 2015 at 21:29:17 UTC, Nordlöw wrote:
I solved at
Project Properties =>
C/C++ Build =>
Build command: make ENABLE_DEBUG=1 -j8
Try it out!
Thanks once again, D folks.
Further, to make expression.c (14klines!) by analyzed
Intellisense change the limit
at
Preferences
On Wednesday, 4 February 2015 at 21:24:22 UTC, Dicebot wrote:
On Wednesday, 4 February 2015 at 21:16:15 UTC, Nordlöw wrote:
BTW: I still can't the debugger to find source information.
How and where do I the debug build configuration to call make
with
ENABLE_DEBUG=1
as argument?
I tend to s
On Wednesday, 4 February 2015 at 21:16:15 UTC, Nordlöw wrote:
BTW: I still can't the debugger to find source information.
How and where do I the debug build configuration to call make
with
ENABLE_DEBUG=1
as argument?
I tend to simply edit posix.mak and change CFLAGS there :)
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear
On Wednesday, 4 February 2015 at 20:48:33 UTC, Daniel Kozak wrote:
What do I have to do to make this work? Please help.
Project->Properties
here select use project settings
and setup *.c as c++ source files and *.h as c++ header files
than Project->C/C++ Index-> Rebuild
Thanks. So I should
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear
On 2/4/2015 12:42 PM, Foo wrote:
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei Alexandrescu wrote:
@trusted
@nogc
char[] read(const string filename) nothrow {
Yes that is correct, currently there is no error checking, maybe it get that
later. But what do you mean with "it use more opera
On Wednesday, 4 February 2015 at 20:32:35 UTC, Nordlöw wrote:
On Wednesday, 4 February 2015 at 12:08:18 UTC, Daniel Kozak
wrote:
"Nordlöw" via Digitalmars-d píše v St 04. 02. 2015 v 10:25
+:
On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote:
> Can we please change the file extension
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear
On Wednesday, 4 February 2015 at 20:15:37 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 9:13 AM, Foo wrote:
For what it's worth, today I finished the current work. Now we
will
start working with it. If someone has critique, improvement
suggestions
or want to take some ideas, he is free to do so.
T
On Wednesday, 4 February 2015 at 12:08:18 UTC, Daniel Kozak wrote:
"Nordlöw" via Digitalmars-d píše v St 04. 02. 2015 v 10:25
+:
On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote:
> Can we please change the file extensions in DMD from .c to
> .cpp for C++ sources?
If someone (mayb
On 2/4/15 9:13 AM, Foo wrote:
For what it's worth, today I finished the current work. Now we will
start working with it. If someone has critique, improvement suggestions
or want to take some ideas, he is free to do so.
To repeat myself: we rewrote some functionality which already existed in
D, bu
On 2/4/15 10:31 AM, Russel Winder via Digitalmars-d wrote:
(**) Yes you read that right, the Go team have switched from Mercurial
to Git. This is not because they were unhappy with Mercurial, it is
because they were unhappy with Rietveld and switched to Gerrit for
their changeset handing. The Go
On 2/4/2015 10:31 AM, Russel Winder via Digitalmars-d wrote:
The Go team do not use pull requests at all,
everything goes through a review manager, now that is Gerrit. Mayhap D
could follow the Go example?
We'd need an awful good reason to ditch the PR system we use now.
1 - 100 of 187 matches
Mail list logo
