On Sunday, 8 February 2015 at 19:52:26 UTC, Jacob Carlborg wrote:
On 2015-02-08 12:06, Vladimir Panteleev wrote:
Neither of these will help in resolving the module path and
filesystem
path inconsistency, while maintaining compatibility with the
git
submodule approach.
I'm not exactly sure w
On Sunday, 8 February 2015 at 21:02:14 UTC, Jacob Carlborg wrote:
The above command will obviously not compile "bar.d". What I
mean is that it's no longer enough to pass a single file and
let RDMD track the dependencies.
OK, but the obviously trivial fix is to either import bar, or
create a m
On 02/08/2015 10:33 PM, Dicebot wrote:
> Trivial proof of concept : https://github.com/Dicebot/TestDlangAggregated
Great idea. I've been using the following one just to keep up-to-date
with git head dmd and Phobos:
https://github.com/carlor/dlang-workspace
Ali
After some discussions on topic I decided to have a look how it
actually may look in practice and experience was mostly pleasing
so far.
Trivial proof of concept :
https://github.com/Dicebot/TestDlangAggregated
Idea is to create an aggregated repository as part of
D-Programming-Language org
On Sun, Feb 08, 2015 at 06:06:59PM -0800, Walter Bright via Digitalmars-d wrote:
> I.e. by providing standard mockups for components, and standard tests
> for component protocols, we can significantly improve the unit testing
> and standard conformance of user designed components.
Yes, I've sugges
On 2/8/2015 6:08 PM, Walter Bright wrote:
On 2/8/2015 5:52 PM, Jakob Ovrum wrote:
On Monday, 9 February 2015 at 01:41:33 UTC, Walter Bright wrote:
Anyone interested in taking up this flag?
Is this idea different from the one in std.internal.test.dummyrange?
I wasn't aware of the existence o
On Sun, Feb 08, 2015 at 06:08:31PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/8/2015 5:52 PM, Jakob Ovrum wrote:
> >On Monday, 9 February 2015 at 01:41:33 UTC, Walter Bright wrote:
> >>Anyone interested in taking up this flag?
> >
> >Is this idea different from the one in std.internal.tes
I.e. by providing standard mockups for components, and standard tests for
component protocols, we can significantly improve the unit testing and standard
conformance of user designed components.
On 2/8/2015 5:52 PM, Jakob Ovrum wrote:
On Monday, 9 February 2015 at 01:41:33 UTC, Walter Bright wrote:
Anyone interested in taking up this flag?
Is this idea different from the one in std.internal.test.dummyrange?
I wasn't aware of the existence of that. Will check it out.
On Monday, 9 February 2015 at 01:41:33 UTC, Walter Bright wrote:
More and more, D code is written as a component that takes a
type parameters that are ranges. Unit testing becomes
inconvenient, as types must be mocked up to call them. Using an
array of data often is inadequate, because the comp
On Monday, 9 February 2015 at 01:41:33 UTC, Walter Bright wrote:
Anyone interested in taking up this flag?
Is this idea different from the one in
std.internal.test.dummyrange?
More and more, D code is written as a component that takes a type parameters
that are ranges. Unit testing becomes inconvenient, as types must be mocked up
to call them. Using an array of data often is inadequate, because the component
may have specializations for an array, or specifies a range
On Sunday, 8 February 2015 at 13:13:18 UTC, Marc Schütz wrote:
On Sunday, 8 February 2015 at 01:57:55 UTC, Meta wrote:
On Sunday, 8 February 2015 at 00:31:42 UTC, Mike wrote:
Is `this` overloaded to mean "this class" in a static context
or is `this` only valid in a non-static context. Please
On 2015-02-05 09:56, Atila Neves wrote:
It depends on how you define "out of the box", I guess.
I define it as what's included in a newly installed operating system.
The biggest issue here is Windows vs Posix.
--
/Jacob Carlborg
On 2015-02-04 19:07, Vladimir Panteleev wrote:
You mean via extern(C)?
You can use pragma(lib), and the compiler will emit a linker instruction
to add the specified library. I'm not sure about the platform support,
though.
No, I mean like this:
module mylib.foo;
void foo () {}
module myli
On 2015-02-03 22:02, H. S. Teoh via Digitalmars-d wrote:
Second generation build algorithms are centered around *not* scanning,
but taking advantage of modern OSes providing APIs for file change
notification. Rather than scan the whole source tree every time, it
takes the changeset as input -- e
On 2015-02-08 17:57, Andrei Alexandrescu wrote:
Ehm. This part sounds unnecessarily a bit political - NIH syndrome,
closemindedness of the D folks toward using anything else but D and
make, and such.
I'm just sharing my experience since I've tried this before. I would not
recommend using any
On Sunday, 8 February 2015 at 13:13:18 UTC, Marc Schütz wrote:
On Sunday, 8 February 2015 at 01:57:55 UTC, Meta wrote:
On Sunday, 8 February 2015 at 00:31:42 UTC, Mike wrote:
Is `this` overloaded to mean "this class" in a static context
or is `this` only valid in a non-static context. Please
On Sunday, 8 February 2015 at 13:06:08 UTC, Marc Schütz wrote:
No, `alias this` convert from the type it is declared in to
another type. `opImplicitCast` would be declared in the
destination type.
So like this?
struct Type1
{
string str;
}
struct Type2
{
string str;
Type2 opImpl
On 2015-02-08 14:59, Russel Winder via Digitalmars-d wrote:
I worked on Rant for a while because Rake is not up to building C and
C++ systems due to lack of abstractions. As far as I can tell Rake
remain the de facto standard tool in the Ruby community and absolutely
nowhere else.
Since Rake w
On 2015-02-08 12:06, Vladimir Panteleev wrote:
Neither of these will help in resolving the module path and filesystem
path inconsistency, while maintaining compatibility with the git
submodule approach.
I'm not exactly sure what you're looking for but with these fields you
can configure the s
On Sunday, 8 February 2015 at 17:59:56 UTC, Jacob Carlborg wrote:
On 2015-02-06 12:37, Dicebot wrote:
D is only cross-platfrom scripting language we can rely on.
This is
probably biggest problem of make (apart from bunch of legacy
syntax
crap) - any real build system needs relatively complicat
On Sunday, 8 February 2015 at 15:28:10 UTC, Vladimir Panteleev
wrote:
On Sunday, 8 February 2015 at 15:20:17 UTC, karl wrote:
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
If you don't want to write "base" twice, you can writ
On 2015-02-06 12:37, Dicebot wrote:
D is only cross-platfrom scripting language we can rely on. This is
probably biggest problem of make (apart from bunch of legacy syntax
crap) - any real build system needs relatively complicated build rules
for target transformation. However we can reasonably
On Sunday, 8 February 2015 at 17:12:20 UTC, Daniel Murphy wrote:
"Zach the Mystic" wrote in message
news:qxtyqdeewrjurmwhk...@forum.dlang.org...
I don't know how the second assert could men somethign
different from the first. If you assert (anything but
assert(0)) first thing, you certainly
"Zach the Mystic" wrote in message
news:qxtyqdeewrjurmwhk...@forum.dlang.org...
I don't know how the second assert could men somethign different from the
first. If you assert (anything but assert(0)) first thing, you certainly
are not checking for bugs *within* the function - you're checking
On Sunday, 8 February 2015 at 15:23:13 UTC, Orvid King wrote:
No, because that looks like it should be indexing a uniform
multi-dimensional array, which it very definitely is not.
Oh, I didn't notice that conflict. So ok, disregard this
suggestion. I'll just use methods like the .slice(int,int
On 2/8/15 3:00 AM, Jacob Carlborg wrote:
On 2015-02-03 19:00, Russel Winder via Digitalmars-d wrote:
Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build
system using Scala programs as input.
Some Scala folk got religious about Scala being the only right language
for Scala builds
On Sunday, 8 February 2015 at 13:03:28 UTC, Marc Schütz wrote:
On Thursday, 5 February 2015 at 16:34:38 UTC, Zach the Mystic
wrote:
Can you name one, or even imagine one? Bear in mind people
like Andrei and myself do not like to read or write the later
form and will use it much less, regardless
On 2/8/15 5:16 AM, John Colvin wrote:
On Sunday, 8 February 2015 at 12:43:38 UTC, FG wrote:
On 2015-02-08 at 03:19, Andrei Alexandrescu wrote:
Indeed we have no safe way to wrap free.
How about this to prevent double free:
Wrapped malloc keeps a static thread-local lookup structure for
succe
On Sunday, 8 February 2015 at 15:20:17 UTC, karl wrote:
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
Maybe such syntax would be a welcome addition to D? I don't see
it conflicting with the existing grammar, and only the 2
sl
We still have quite a few features which are listed as
to-be-deprecated, but without any dates listed:
http://dlang.org/deprecate.html
So, what's the status of these?
On 2/8/15 2:54 AM, Johannes Pfau wrote:
Am Sat, 07 Feb 2015 15:50:53 -0800
schrieb Andrei Alexandrescu :
@trusted int setvbuf(T)(FILE* stream, T[] buf, int mode)
if (is(T == char) || is(T == byte) || is(T == ubyte))
{
return setvbuf(stream, cast(char*) buf.ptr, mode, buf.length);
}
This
On Sunday, 8 February 2015 at 15:20:17 UTC, karl wrote:
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
If you don't want to write "base" twice, you can write:
result = src[base..$][0..size];
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
Maybe such syntax would be a welcome addition to D? I don't see
it conflicting with the existing grammar, and only the 2
slicing-operators need further extending to support it.
On Sunday, 8 February 2015 at 15:20:17 UTC, karl wrote:
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
Maybe such syntax would be a welcome addition to D? I don't see
it conflicting with the existing grammar, and only the 2
sl
On 2015-02-08 at 14:59, Russel Winder via Digitalmars-d wrote:
Well clearly it should be rejected, you have to s/Ruby/Python/ ;-)
LOL
As far as I can tell Rake remain the de facto standard tool
in the Ruby community and absolutely nowhere else.
That's by design. A rake gathers hay towards t
On Sun, 2015-02-08 at 12:00 +0100, Jacob Carlborg via Digitalmars-d wrote:
>
[…]
> It's kind of the same in the D community. Before Dub existed I
> started to work on both a package manager (Orbit) and a build tool
> (never officially announced). I used Ruby as the description format
> for pack
On Sunday, 8 February 2015 at 12:43:38 UTC, FG wrote:
On 2015-02-08 at 03:19, Andrei Alexandrescu wrote:
Indeed we have no safe way to wrap free.
How about this to prevent double free:
Wrapped malloc keeps a static thread-local lookup structure for
successful allocations (if having to releas
On Sunday, 8 February 2015 at 12:43:38 UTC, FG wrote:
On 2015-02-08 at 03:19, Andrei Alexandrescu wrote:
Indeed we have no safe way to wrap free.
How about this to prevent double free:
Wrapped malloc keeps a static thread-local lookup structure for
successful allocations (if having to releas
On Sunday, 8 February 2015 at 01:57:55 UTC, Meta wrote:
On Sunday, 8 February 2015 at 00:31:42 UTC, Mike wrote:
Is `this` overloaded to mean "this class" in a static context
or is `this` only valid in a non-static context. Please
clarify, and if it's a bug, help me understand so I can make
an
On Saturday, 7 February 2015 at 20:53:48 UTC, Meta wrote:
On Saturday, 7 February 2015 at 19:38:10 UTC, Marc Schütz wrote:
On Saturday, 7 February 2015 at 05:27:39 UTC, Andrei
Alexandrescu wrote:
On 2/6/15 8:28 PM, Jonathan Marler wrote:
Do you know if D might support that later or if there's a
On Thursday, 5 February 2015 at 16:34:38 UTC, Zach the Mystic
wrote:
Can you name one, or even imagine one? Bear in mind people like
Andrei and myself do not like to read or write the later form
and will use it much less, regardless of benefit.
Daniel Murphy has (function stubs with `assert(0)
On 2015-02-08 at 03:19, Andrei Alexandrescu wrote:
Indeed we have no safe way to wrap free.
How about this to prevent double free:
Wrapped malloc keeps a static thread-local lookup structure for successful
allocations (if having to release memory from the same thread is an acceptable
require
On Tuesday, 3 February 2015 at 01:33:32 UTC, deadalnix wrote:
On Tuesday, 3 February 2015 at 00:59:26 UTC, Andrei
Alexandrescu wrote:
On 2/2/15 4:23 PM, eles 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
On Thursday, 5 February 2015 at 00:37:31 UTC, 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
On Sunday, 8 February 2015 at 10:39:22 UTC, Jacob Carlborg wrote:
On 2015-02-07 20:17, Vladimir Panteleev wrote:
I don't see how this setting is at all relevant to the problem
at hand.
Yes, sorry, "sourcePaths" and "importPaths" were the fields I
was thinking about. Although I think "mainSou
On 2015-02-03 19:00, Russel Winder via Digitalmars-d wrote:
Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build
system using Scala programs as input.
Some Scala folk got religious about Scala being the only right language
for Scala builds, and created what has become SBT. Because
On Thursday, 29 January 2015 at 08:05:28 UTC, Laeeth Isharc wrote:
On Wednesday, 28 January 2015 at 18:46:05 UTC, Benjamin Thaut
wrote:
Am 28.01.2015 um 18:05 schrieb Andrei Alexandrescu:
On 1/28/15 9:01 AM, Benjamin Thaut wrote:
On Wednesday, 28 January 2015 at 16:18:18 UTC, Andrei
Alexandres
Am Sat, 07 Feb 2015 15:50:53 -0800
schrieb Andrei Alexandrescu :
> I was looking into ways to make core.stdc safer. That should be
> relatively easy to do by defining a few wrappers. For example:
This might be a good idea, but it might also be more difficult than you
think:
>
> int setvbuf(FI
On 2015-02-08 01:39, Mike Parker wrote:
But apparently this can be done now with dub.selections.json.
Yes, exactly. I just replied to someone calming updating packages
automatically was a good idea. I also had to fight quite a lot to get
this feature into Dub.
--
/Jacob Carlborg
On 2015-02-07 20:17, Vladimir Panteleev wrote:
I don't see how this setting is at all relevant to the problem at hand.
Yes, sorry, "sourcePaths" and "importPaths" were the fields I was
thinking about. Although I think "mainSourceFile" may be needed as well,
otherwise dub will look for "app.d
come to think of it, is there any point in making malloc
@safe/@trusted
at all? I don't think it's possible to make free() @safe, so
what's the
purpose of making malloc callable from @safe code?
At least two programs, widely used by folks here, never release
their memory. Those could be made
H. S. Teoh:
Come to think of it, is there any point in making malloc
@safe/@trusted at all?
I am not asking for a @trusted function. I'd like a @system
template wrapper for malloc/calloc/free that is safer than the C
functions (safer because it's type-aware).
Bye,
bearophile
On 2015-02-05 22:35, Walter Bright wrote:
It's no different from:
Q: the compiler gave me a mismatched type error!
A: put in a cast and it'll compile!
The difference is if you do that the compiler won't disable type
checking for the whole function.
--
/Jacob Carlborg
On Sunday, 8 February 2015 at 04:45:55 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 8:21 PM, H. S. Teoh via Digitalmars-d wrote:
Come to think of it, is there any point in making malloc
@safe/@trusted
at all? I don't think it's possible to make free() @safe, so
what's the
purpose of making malloc
On Sat, 07 Feb 2015 13:02:58 +, Craig Dillabaugh wrote:
> On Saturday, 7 February 2015 at 06:23:43 UTC, ketmar wrote:
>> On Fri, 06 Feb 2015 18:48:16 +, deadalnix wrote:
>>
>>> Well you are talking for talking, we are waiting on your awesome PRs.
>>
>> easy deal. and i'm waiting for Andrei
57 matches
Mail list logo
