On Thursday, 3 January 2013 at 00:13:41 UTC, H. S. Teoh wrote:
On Thu, Jan 03, 2013 at 12:53:56AM +0100, David Nadlinger wrote:
On Wednesday, 2 January 2013 at 23:08:14 UTC, H. S. Teoh wrote:
>All extern(C) functions must be @system by default. It makes
>no sense
>to allow a @safe extern(C) fun
On 01/03/2013 12:48 AM, Jason House wrote:
...
ref int bar()
{
int i = 7;
return foo(i);
}
If @safe, this code will not compile.
Error: foo may return a local stack variable
Since "i" is a local variable, "foo(i)" might return it.
ref int baz(int i)
{
return foo(i);
}
This
On Thursday, 3 January 2013 at 04:40:59 UTC, SomeDude wrote:
For other projects, D still doesn't have a nice unified
interface to databases.
Actually, there is a project called adbi for the database
interface.
A full featured precise, generational, concurrent GC would be a
nice project
On 03.01.2013 08:02, Nathan M. Swan wrote:
Here's my proposal for a D Package Manager. I want to make sure it has a
good design before I write any code, so here it is:
http://wiki.dlang.org/User:Nathan_M._Swan/DPM_Proposal
I know there are many gaps in this, I want to see which are the most
imp
On 03.01.2013 09:33, David Nadlinger wrote:
Sorry for being a bit blunt, but: What advantages would this provide
over just using the package management facilities of one's favorite
distro? Keep in mind: http://xkcd.com/927/ ;)
If you want to distribute your software or library to multiple dis
On Wednesday, 2 January 2013 at 17:06:09 UTC, deadalnix wrote:
On Wednesday, 2 January 2013 at 16:15:00 UTC, Ishan Thilina
Somasiri wrote:
I think the strongest need for D right now is a better GC. A
very
good start would be to make the GC precise on the heap. Compiler
support have been implem
Dmitry Olshansky:
Yup, and it's 2 lines then. And if one really wants to chain it:
map(a => enforce(std.ascii.isNumeric(a)), a -= '0')(...);
Hardly makes it Phobos candidate then ;)
I think you meant to write:
map(a => enforce(std.ascii.isNumeric(a)), a - '0')(...);
To avoid some bugs I try
On Thursday, 3 January 2013 at 00:59:04 UTC, Walter Bright wrote:
As always, when I try to do a release, problems crop up. For
example,
the github procedure agreed upon and outlined here:
http://wiki.dlang.org/Proposed_new_D_development_process#Release_a_new_version_of_D
Issues:
1. you cannot
On 1/2/2013 2:03 PM, David wrote:
Not even a single word, thanks
I don't really see the issue. I created the repository for your project, and
pulled your pull requests. The workflow is deliberately designed so more than
one person needs to be involved to get the stuff online.
As always, when I try to do a release, problems crop up. For example,
the github procedure agreed upon and outlined here:
http://wiki.dlang.org/Proposed_new_D_development_process#Release_a_new_version_of_D
Issues:
1. you cannot have a tag and a branch with the same name. At least, you cannot
p
On Thu, Jan 03, 2013 at 12:53:56AM +0100, David Nadlinger wrote:
> On Wednesday, 2 January 2013 at 23:08:14 UTC, H. S. Teoh wrote:
> >All extern(C) functions must be @system by default. It makes no sense
> >to allow a @safe extern(C) function, since there is no way for the
> >compiler to verify any
On Wednesday, 2 January 2013 at 23:08:14 UTC, H. S. Teoh wrote:
All extern(C) functions must be @system by default. It makes no
sense to
allow a @safe extern(C) function, since there is no way for the
compiler
to verify anything at all. The best you can do is @trusted.
@trusted shouldn't be a
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis
wrote:
After some recent discussions relating to auto ref and const
ref, I have come
to the conlusion that as it stands, ref is not @safe. It's
@system. And I
think that we need to take a serious look at it to see what we
can do to m
On 1/2/13 5:21 PM, Maxim Fomin wrote:
On Wednesday, 2 January 2013 at 19:37:51 UTC, Jonathan M Davis wrote:
On Wednesday, January 02, 2013 13:45:32 Maxim Fomin wrote:
I think it should not be fixed, but probably compiler may issue
warning at some circumstances when it can realize this situation
On Wed, Jan 02, 2013 at 06:30:38PM -0500, Jonathan M Davis wrote:
> On Wednesday, January 02, 2013 15:06:24 H. S. Teoh wrote:
> > All extern(C) functions must be @system by default. It makes no sense to
> > allow a @safe extern(C) function, since there is no way for the compiler
> > to verify anyth
On Wednesday, 2 January 2013 at 22:53:04 UTC, Jonathan M Davis
wrote:
Then we're going to have to disagree, and I believe that Walter
and Andrei are
completely with me on this one. If all of the constructs that
you use are
@safe, then it should be _guaranteed_ that your program is
memory-safe.
On Wednesday, January 02, 2013 15:06:24 H. S. Teoh wrote:
> All extern(C) functions must be @system by default. It makes no sense to
> allow a @safe extern(C) function, since there is no way for the compiler
> to verify anything at all. The best you can do is @trusted.
Agreed. And @trusted is seri
On Wednesday, 2 January 2013 at 21:12:33 UTC, Maxim Fomin wrote:
On Wednesday, 2 January 2013 at 21:00:10 UTC, Michael wrote:
R With(I, R)(I o, R function (I) fun)
{
static if(isAssignable!(I, typeof(null)))
return o is null ? null : fun(o);
else
On Wed, Jan 02, 2013 at 11:15:31PM +0100, monarch_dodra wrote:
> On Wednesday, 2 January 2013 at 20:49:38 UTC, Dmitry Olshansky
> wrote:
> >
> >Yup, and it's 2 lines then. And if one really wants to chain it:
> >map(a => enforce(std.ascii.isNumeric(a)), a -= '0')(...);
> >
> >Hardly makes it Phobos
On Wed, Jan 02, 2013 at 05:52:54PM -0500, Jonathan M Davis wrote:
> On Wednesday, January 02, 2013 23:21:55 Maxim Fomin wrote:
> > Again, I argue that D is a system language and there are many
> > possibilities to break @safity. Although fixing holes does make
> > sense in general, it does not make
On Wednesday, January 02, 2013 23:21:55 Maxim Fomin wrote:
> Again, I argue that D is a system language and there are many
> possibilities to break @safity. Although fixing holes does make
> sense in general, it does not make sense fixing obvious issues so
> that plenty of code becomes uncompilable
On Wednesday, 2 January 2013 at 11:41:33 UTC,
DythroposTheImposter wrote:
I'm interested in how the new LuaJIT GC ends up performing.
But overall I can't say I have much hope for GC right now.
GC/D = Generally Faster allocation. Has a cost associated with
every living object.
C++ = Genera
On 2013-01-02 22:26, deadalnix wrote:
Indeed, I work on SDC, and a lot of work need to be done. However, I'm
not sure how to staff 4 person on it, and i'm sure the GC things is more
beneficial for D in general (and is in the scope).
Just need to figure out what needs to be done and assign diff
On 2013-01-02 22:02, Nathan M. Swan wrote:
Here's my proposal for a D Package Manager. I want to make sure it has a
good design before I write any code, so here it is:
http://wiki.dlang.org/User:Nathan_M._Swan/DPM_Proposal
I know there are many gaps in this, I want to see which are the most
imp
On Wednesday, 2 January 2013 at 21:02:51 UTC, Nathan M. Swan
wrote:
Here's my proposal for a D Package Manager. I want to make sure
it has a good design before I write any code, so here it is:
http://wiki.dlang.org/User:Nathan_M._Swan/DPM_Proposal
Sorry for being a bit blunt, but: What advant
On Wednesday, January 02, 2013 23:02:12 monarch_dodra wrote:
> That said, I think another field of improvement we should
> concentrate in phobos is to have a single public entry point, and
> then privately forward to private specialized overloads.
>
> Users really shouldn't have to deal with funct
On Wednesday, 2 January 2013 at 19:37:51 UTC, Jonathan M Davis
wrote:
On Wednesday, January 02, 2013 13:45:32 Maxim Fomin wrote:
I think it should not be fixed, but probably compiler may issue
warning at some circumstances when it can realize this
situation.
It's a hole in @safe. It must be f
On Wednesday, 2 January 2013 at 20:49:38 UTC, Dmitry Olshansky
wrote:
Yup, and it's 2 lines then. And if one really wants to chain it:
map(a => enforce(std.ascii.isNumeric(a)), a -= '0')(...);
Hardly makes it Phobos candidate then ;)
Well, just because its almost trivial to us doesn't mean it
On Monday, December 31, 2012 15:58:02 Peter Alexander wrote:
> On Monday, 31 December 2012 at 14:24:53 UTC, monarch_dodra wrote:
> > The same can't be said about ranges: a "immutable(Range!T)"
> > might not safely copyable as a "Range!(immutable(T))"
>
> Hmm, are you sure? Can you give an example?
On Wednesday, 2 January 2013 at 21:43:31 UTC, Jonathan M Davis
wrote:
On Thursday, January 03, 2013 01:25:17 Dmitry Olshansky wrote:
What do you think?
Hmmm. Typically the thing that you really want to know is which
portions were
true and which were false, and this doesn't help with that at
Not even a single word, thanks
On Sunday, 30 December 2012 at 22:08:59 UTC, Jonathan M Davis
wrote:
On Sunday, December 30, 2012 19:23:13 SomeDude wrote:
AFAIK, no 32-bit OS supports files larger than 4Gb anyway.
Um. No. There's a reason that things like the macro
_LARGE_FILE_API exist.
While some file systems won't allow
On Thursday, January 03, 2013 01:25:17 Dmitry Olshansky wrote:
> What do you think?
Hmmm. Typically the thing that you really want to know is which portions were
true and which were false, and this doesn't help with that at all. What it
does is make the errors more understandable for newbies, wh
On Wednesday, 2 January 2013 at 17:18:52 UTC, Thiez wrote:
On Wednesday, 2 January 2013 at 12:32:01 UTC, deadalnix wrote:
Most GC language lack proper memory management, and sometime
have design choice that are a nightmare for the GC (java have
no value type for instance).
Surely Java's primi
On Wednesday, 2 January 2013 at 17:39:06 UTC, Jacob Carlborg
wrote:
* Since you ask and mentioned compilers I would say a
lexer/parser/front end written in D. This should be usable as a
library which the following could be build upon:
* Syntax highlighter
* Compiler
* Refactoring
* Static anal
The proposal is to extend template constraint from:
if()
to
if(; )
Where the is CTFE-able expression with type string.
The message-expr yields a hint string for compiler to show when
instantiation failed instead of full expression that failed. It has to
be CTFE-able even if template instant
On Wednesday, 2 January 2013 at 21:00:10 UTC, Michael wrote:
R With(I, R)(I o, R function (I) fun)
{
static if(isAssignable!(I, typeof(null)))
return o is null ? null : fun(o);
else
return fun(o);
}
class Person
{
private
{
Here's my proposal for a D Package Manager. I want to make sure
it has a good design before I write any code, so here it is:
http://wiki.dlang.org/User:Nathan_M._Swan/DPM_Proposal
I know there are many gaps in this, I want to see which are the
most important to fill.
I plan to make a central
R With(I, R)(I o, R function (I) fun)
{
static if(isAssignable!(I, typeof(null)))
return o is null ? null : fun(o);
else
return fun(o);
}
class Person
{
private
{
string _name;
Address _address;
1/3/2013 12:21 AM, Andrei Alexandrescu пишет:
On 1/2/13 3:13 PM, Dmitry Olshansky wrote:
1/2/2013 7:24 PM, bearophile пишет:
monarch_dodra:
The rationale for this:
std.ascii: I think returning -1 as a magic number should help keep the
code faster and with less clutter than with exceptions.
On 1/2/13 3:13 PM, Dmitry Olshansky wrote:
1/2/2013 7:24 PM, bearophile пишет:
monarch_dodra:
The rationale for this:
std.ascii: I think returning -1 as a magic number should help keep the
code faster and with less clutter than with exceptions.
For the ASCII version I have two use cases:
- W
1/2/2013 7:24 PM, bearophile пишет:
monarch_dodra:
The rationale for this:
std.ascii: I think returning -1 as a magic number should help keep the
code faster and with less clutter than with exceptions.
For the ASCII version I have two use cases:
- Where I want to go fast&unsafe I just use "c
Consider this:
import std.stdio;
struct S
{
int[] data;
this(this) { writeln("postblit"); data = data.dup; }
~this() { writeln("dtor"); data = null; }
}
auto foo()
{
S s = S([0]);
return { assert(s.data !is null); } ;
}
void main()
{
auto dg = fo
On Tuesday, 1 January 2013 at 16:31:55 UTC, Stewart Gordon wrote:
But there is something called packratting, which is a mistake
at the code level of keeping a pointer hanging around for
longer than necessary and therefore preventing whatever it's
pointing to from being GC'd.
I've heard it ca
On Wednesday, 2 January 2013 at 17:18:52 UTC, Thiez wrote:
On Wednesday, 2 January 2013 at 12:32:01 UTC, deadalnix wrote:
Most GC language lack proper memory management, and sometime
have design choice that are a nightmare for the GC (java have
no value type for instance).
Surely Java's primi
On Wednesday, January 02, 2013 13:45:32 Maxim Fomin wrote:
> I think it should not be fixed, but probably compiler may issue
> warning at some circumstances when it can realize this situation.
It's a hole in @safe. It must be fixed. That's not even vaguely up for
discussion. The question is _how_
Almost all YouTube videos are HTML5-ready.
Really?? I thought youtube still uses Flash. I'm no fan of
youtube, but
it *is* a significant data point, considering that some people
are
actually making a living off homemade videos posted on youtube.
On Wed, Jan 02, 2013 at 01:05:59PM -0500, Nick Sabalausky wrote:
> On Tue, 01 Jan 2013 14:24:52 -0800
> Jonathan M Davis wrote:
>
> > On Tuesday, January 01, 2013 22:31:32 Simen Kjaeraas wrote:
> > > > Understatement of the year. :-P
> > >
> > > Already? Wow.
> >
> > LOL.
> >
> > Well, it's ac
On Wednesday, 2 January 2013 at 18:09:34 UTC, Ali Çehreli wrote:
This issue has come up on the D.learn forum recently. The
following program terminates with
core.exception.InvalidMemoryOperationError. (Tested with dmd
2.061 and 2.060)
string foo()
{
return "a";
}
class Foo
{
~this()
On Wednesday, 2 January 2013 at 17:22:57 UTC, monarch_dodra wrote:
On Wednesday, 2 January 2013 at 17:02:48 UTC, Chris wrote:
You could reduce burden by using raw strings:
auto asso = `["key1":"value1", "key2":"value2"]`;
Yes, I just thought it might be handy for reading user defined
files li
On 01/02/2013 01:07 AM, monarch_dodra wrote:
> I was wondering: Does Phobos require that user defined opEquals (and
> opCmp) be const?
Sorry that I am not adding to this topic directly but I will repeat an
observation of mine. My experience is with C++ and D; if there are
solutions to this issu
This issue has come up on the D.learn forum recently. The following
program terminates with core.exception.InvalidMemoryOperationError.
(Tested with dmd 2.061 and 2.060)
string foo()
{
return "a";
}
class Foo
{
~this()
{
auto s = foo() ~ "b";
}
}
void main()
{
new
On Tue, 01 Jan 2013 14:24:52 -0800
Jonathan M Davis wrote:
> On Tuesday, January 01, 2013 22:31:32 Simen Kjaeraas wrote:
> > > Understatement of the year. :-P
> >
> > Already? Wow.
>
> LOL.
>
> Well, it's actually very easy to make the understatement of the year
> when there have been very few
On 2013-01-02 17:14, Ishan Thilina Somasiri wrote:
Hi,
I'm posting this on bhalf of a group of 4 students from the final
year of Department of Computer Science and Engineering,University
of Moratuwa, Sri Lanka. We are required to do a 8 months long
project in our final year. The
project should c
On Wednesday, 2 January 2013 at 17:06:50 UTC, bearophile wrote:
Chris:
Couldn't the parser infer from string[string] that the
key:value pairs should be treated as strings, regardless of
whether they are quoted or not?
That parser is meant to be used to de-serialize simple D data
structures
On Wednesday, 2 January 2013 at 17:02:48 UTC, Chris wrote:
I was playing around with std.conv.parse's mechanism for
parsing associative arrays from strings (cf.
http://dlang.org/phobos/std_conv.html#parse). A handy feature
as it would allow user-friendly input formats that can be
transformed i
On Wednesday, 2 January 2013 at 12:32:01 UTC, deadalnix wrote:
Most GC language lack proper memory management, and sometime
have design choice that are a nightmare for the GC (java have
no value type for instance).
Surely Java's primitive types (byte, short, int, long, float,
double, boolean,
Chris:
Couldn't the parser infer from string[string] that the
key:value pairs should be treated as strings, regardless of
whether they are quoted or not?
That parser is meant to be used to de-serialize simple D data
structures printed (serialized) with writeln.
Bye,
bearophile
On Wednesday, 2 January 2013 at 16:15:00 UTC, Ishan Thilina
Somasiri wrote:
Hi,
I'm posting this on bhalf of a group of 4 students from the
final
year of Department of Computer Science and
Engineering,University
of Moratuwa, Sri Lanka. We are required to do a 8 months long
project in our fina
I was playing around with std.conv.parse's mechanism for parsing
associative arrays from strings (cf.
http://dlang.org/phobos/std_conv.html#parse). A handy feature as
it would allow user-friendly input formats that can be
transformed into a D-array. However, the parser is very finicky
and expe
Ishan Thilina Somasiri:
We are required to do a 8 months long project in our final
year. The project should consist of both a research and
development component and an implementation. Our group
is interested in areas such as,
* Information security
* Cloud
* Parallel computing
* Com
Cool !
It's like 'Google summer of code' ...
Hi,
I'm posting this on bhalf of a group of 4 students from the final
year of Department of Computer Science and Engineering,University
of Moratuwa, Sri Lanka. We are required to do a 8 months long
project in our final year. The
project should consist of both a research and development
component
monarch_dodra:
The rationale for this:
std.ascii: I think returning -1 as a magic number should help
keep the code faster and with less clutter than with exceptions.
For the ASCII version I have two use cases:
- Where I want to go fast&unsafe I just use "c - '0'".
- When I want more safety I'
There is an ER that would allow to convert characters to numebers:
http://d.puremagic.com/issues/show_bug.cgi?id=5543
For example: '1' => 1
Or, unicode considered: 'Ⅶ' => 7
Long story short, it was decided that it wasn't std.conv.to's job
to do this conversion, but rather, there should be a fun
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis
wrote:
After some recent discussions relating to auto ref and const
ref, I have come
to the conlusion that as it stands, ref is not @safe. It's
@system.
This is not a surprise, I remember Andrei was talking about it
1.5 year ago.
On Wednesday, 2 January 2013 at 11:41:33 UTC,
DythroposTheImposter wrote:
I'm interested in how the new LuaJIT GC ends up performing.
But overall I can't say I have much hope for GC right now.
GC/D = Generally Faster allocation. Has a cost associated with
every living object.
True, howev
"Can we simply make it so that the compiler automatically
creates a variable when you pass an rvalue to a non-templated
auto ref function?"
So non-template auto ref parameters are just like ref
parameters, except they will automatically convert rvalues to
lvalues on call by creating a local v
I'm interested in how the new LuaJIT GC ends up performing. But
overall I can't say I have much hope for GC right now.
GC/D = Generally Faster allocation. Has a cost associated with
every living object.
C++ = Generally Slower allocation, but while it is alive there
is no cost.
So as th
On Wednesday, 2 January 2013 at 09:07:31 UTC, monarch_dodra wrote:
Basically, a DList of tuples: Problem:
DList has a "const correct" opEquals, but Tuple's isn't. It has:
//
bool opEquals(R)(R rhs); //1
bool opEquals(R)(R rhs) const; //2
//
The problem is that //2 should really be
On Wednesday, 2 January 2013 at 09:23:55 UTC, Jonathan M Davis
wrote:
On Wednesday, January 02, 2013 10:07:30 monarch_dodra wrote:
I was wondering: Does Phobos require that user defined opEquals
(and opCmp) be const?
If someone wants to define a non-const opAssign, I'd say that's
their problem,
On Wednesday, 2 January 2013 at 09:07:31 UTC, monarch_dodra wrote:
My opinion is that supporting non-const opEquals makes no real
sense, and adds a lot of useless complexity (and inconsistency)
to the code. At best, it means silently accepting erroneous
code... Until it explodes in someone else
On Wednesday, January 02, 2013 10:07:30 monarch_dodra wrote:
> I was wondering: Does Phobos require that user defined opEquals
> (and opCmp) be const?
>
> If someone wants to define a non-const opAssign, I'd say that's
> their problem, but are we (phobos) expected to support it?
>
> The reason I
I was wondering: Does Phobos require that user defined opEquals
(and opCmp) be const?
If someone wants to define a non-const opAssign, I'd say that's
their problem, but are we (phobos) expected to support it?
The reason I ask is because adding support for this means that
every type that wrap
74 matches
Mail list logo
