On 27.10.2011 08:48, Jacob Carlborg wrote:
On 2011-10-26 20:34, Walter Bright wrote:
100 bugs fixed!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.071.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.056.zip
Impressive
On 10/30/2011 11:01 PM, Don wrote:
They do apply. In every case, some code was modified on the D1 compiler. Not all
of the test cases apply to D1 though (sometimes there are bugs in the compiler
internals, where we don't have a D1 test case that triggers them).
Just to chime in, whenever I fix
On 2011-10-31 07:01, Don wrote:
On 27.10.2011 08:48, Jacob Carlborg wrote:
On 2011-10-26 20:34, Walter Bright wrote:
100 bugs fixed!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.071.zip
http://www.digitalmars.com/d/2.0/changelog.html
On 31.10.2011 7:21, Jesse Phillips wrote:
I wish to congratulate Dmitry Olshansky for not only having his project
selected for GSoC, but inclusion into Phobos. Absolutely no one had
objection to this proposal and it received 11 yes votes, myself included.
Dmitry, please merge in the latest
Alex Rønne Petersen wrote:
On 30-10-2011 06:05, Andrew Wiley wrote:
On Sat, Oct 29, 2011 at 10:55 PM, Chante udontspa...@never.will.u
wrote: Manu turkey...@gmail.com mailto:turkey...@gmail.com wrote
in message
news:mailman.586.1319935753.24802.digitalmar...@puremagic.com...
On 30.10.2011 02:49, Manu wrote:
What's the deal with core.cpuid?
I realise it is an x86 opcode, but is that something that you really
want totally bare in core like that?
I'm experimenting with other architectures, and some sort of
core.processorInfo would be really nice, surely an API for this
On 30.10.2011 22:29, bearophile wrote:
I have translated C code similar to:
something foo(int n) {
int *array = malloc(n * sizeof(int));
int i;
for (...) {
for (i = 0; i n; i++, array++) {
*array = ...;
*array = ...;
}
...
}
in std? what's the story with core? is it being deprecated?
I would think that cpuid should be a subset of a generalised sysinfo (or
processorinfo perhaps)... something you can optionally obtain if you first
identify that you're on an x86.
Why would there be a 'higher level' module? I'd like a
Is there a way to do this. For example if I have
struct A { int a, b, c; }
struct B
{
int p, q, r, s;
this(A a) { p = a.a; q = a.b; r = a.c; }
}
A a;
B b;
b = a;
On Sun, 30 Oct 2011 14:13:00 -0500, Andrei Alexandrescu wrote:
On 10/30/11 1:18 PM, Steve Teale wrote:
But the others. Who is Roosevelt, who Eisenhower, Montgomery, Patton
and so on? And most provocatively, who is Stalin?
Pliz pliz don't give me Stalin.
Andrei
Is this like 'anything
I wander every place. Now I am bad. I am bad because I haven't lived a
day without the girl I love. She is old now. But I still love her as I
knew her. Don't you even dare tell me how you don't suck. I hate you.
Because you took her away from me. and I come here trying to find her and
now I
you suck
stupid assholes get the fuck out of my face.
Robert,
Maybe you can fix this along the way:
import std.variant;
struct B
{
int p, q, r, s;
}
typedef B C;
void main()
{
B b;
C c;
b = c; // ok
Variant v = c;
assert(v.convertsTo!(B)); // no dice
}
Steve
But I'm way to tired to stay up and tell you. I'll tell yout next time.
Le 31/10/2011 02:21, Mehrdad a écrit :
I've written this piece of code a fair number of times:
static if (is(typeof(foo( { foo(); }
else { bar(); }
When the expression inside the condition (i.e. the call to foo()) gets
complicated, you get lots of code duplication and things become harder
On Sun, 30 Oct 2011 10:36:26 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 10/30/11 5:16 AM, J Arrizza wrote:
You should use either std.traits.isXxx systematically, or
patterns systematically, but not both at the same time.
Personally I prefer
On Sat, 29 Oct 2011 12:11:42 -0400, J Arrizza cppge...@gmail.com wrote:
Thanks for the reply Jonathan, but it didn't work for me:
void abc(T) (T[] parm1)
if (isDynamicArray!T)
{
writeln(array : , parm1);
}
Nor did:
void abc(T) (T[] parm1)
if (isStaticArray!T)
{
writeln(array : , parm1);
On Sat, 29 Oct 2011 22:14:34 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 10/29/11 7:17 PM, bls wrote:
On 10/29/2011 04:58 PM, Vladimir Panteleev wrote:
td.container seems to have been written by the very same Steven
Schveighoffer.
Just the RBTree portion (and
On Sun, 30 Oct 2011 15:23:59 -0400, dsimcha dsim...@yahoo.com wrote:
On 10/30/2011 3:09 PM, Andrei Alexandrescu wrote:
As the opApply body can never be inlined it is a worse choice in
general.
That was my intuition too.
Andrei
Just for future reference, LDC **DOES** sometimes inline
On 10/31/11 4:43 AM, Steve Teale wrote:
Is there a way to do this. For example if I have
struct A { int a, b, c; }
struct B
{
int p, q, r, s;
this(A a) { p = a.a; q = a.b; r = a.c; }
}
A a;
B b;
b = a;
Use opAssign?
Andrei
On Mon, 31 Oct 2011 06:32:43 -0400, Chante udontspa...@never.will.u
wrote:
But I'm way to tired to stay up and tell you. I'll tell yout next time.
ignoredcontacts += chante.
-Steve
Am 31.10.2011 14:08, schrieb Steven Schveighoffer:
On Mon, 31 Oct 2011 06:32:43 -0400, Chante udontspa...@never.will.u
wrote:
But I'm way to tired to stay up and tell you. I'll tell yout next time.
ignoredcontacts += chante.
-Steve
s/+=/~=
:) that's the D way
Mafi
On Mon, 31 Oct 2011 09:10:20 -0400, Mafi m...@example.org wrote:
Am 31.10.2011 14:08, schrieb Steven Schveighoffer:
On Mon, 31 Oct 2011 06:32:43 -0400, Chante udontspa...@never.will.u
wrote:
But I'm way to tired to stay up and tell you. I'll tell yout next time.
ignoredcontacts += chante.
On Sat, 29 Oct 2011 10:42:54 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 10/26/11 7:18 AM, Steven Schveighoffer wrote:
On Mon, 24 Oct 2011 19:49:43 -0400, Simen Kjaeraas
simen.kja...@gmail.com wrote:
On Mon, 24 Oct 2011 21:41:57 +0200, Steven Schveighoffer
On Sat, 29 Oct 2011 12:02:51 -0400, J Arrizza cppge...@gmail.com wrote:
On Fri, Oct 28, 2011 at 6:55 PM, Steven Schveighoffer
schvei...@yahoo.comwrote:
I'd recommend using a linked list or a deque. Both are available via
dcollections, though using dcollections' deque as a queue is equivalent
typedef shouldn't exist anymore, use alias.
Steve Teale Wrote:
Robert,
Maybe you can fix this along the way:
import std.variant;
struct B
{
int p, q, r, s;
}
typedef B C;
void main()
{
B b;
C c;
b = c; // ok
Variant v = c;
assert(v.convertsTo!(B)); //
I've been looking into cas recently and I came to wonder why it doesn't
provide actual support for pointers.
The current declaration of cas looks roughly like this:
bool cas(shared(T)* here, const V1 ifThis, const V2 writeThis) if
(__traits(compiles,mixin(*here = writeThis)))
which, with
writeThis really shouldn't be const, it should be shared. The problem was that
making writeThis a shared pass by value param implied a synchronized load for
writeThis, which is undesirable for cas. So I left the declaration of cas as
specified in TDPL and thought I'd figure this out later.
Le 30/10/2011 22:46, Jonathan M Davis a écrit :
On Sunday, October 30, 2011 17:29:36 bearophile wrote:
Arrays in D implicitly convert to their ptr property, so they essentially
_are_ pointers in that sense. Now, personally, I think that it would be a good
idea for them _not_ to implicitly
core contains the stuff that is intrinsic to the D language. It's separate from
std for a number of reasons, but one practical reason is to help prevent large
portions of the standard library being pulled into all apps simply because
something in the runtime code wanted to do formatted IO, for
On Fri, 28 Oct 2011 16:18:27 +0300, dsimcha dsim...@yahoo.com wrote:
Docs:
http://nascent.freeshell.org/programming/D/doc/phobos/std_csv.html
Checked the new docs today. If I'm reading them right, the top example
prints:
Fred works as a Fly and earns $4 per year
Is this a pop culture
On Mon, 31 Oct 2011 07:58:11 -0500, Andrei Alexandrescu wrote:
On 10/31/11 4:43 AM, Steve Teale wrote:
Is there a way to do this. For example if I have
struct A { int a, b, c; }
struct B
{
int p, q, r, s;
this(A a) { p = a.a; q = a.b; r = a.c; }
}
A a;
B b;
b = a;
Use
Steve Teale:
But if B is not mine to mess with?
The two structs have a common type prefix. and D guarantees that there
are predictable values for the remainder of the larger one, so the
compiler could presumably figure it out. (Easy for me to say)
Looks like a job for StructuralCast!().
On Mon, 31 Oct 2011 11:50:42 -0400, Jesse Phillips wrote:
typedef shouldn't exist anymore, use alias.
Jesse,
Maybe you want to do something like:
struct X
{
int a;
double b;
}
typedef X Y;
alias X Z;
void discriminate(T)(T t)
{
if (is(T == X))
writeln(It's an X);
else
On 2011-10-31 17:07:31 +, Sean Kelly s...@invisibleduck.org said:
writeThis really shouldn't be const, it should be shared. The problem was t
hat making writeThis a shared pass by value param implied a synchronized loa
d for writeThis, which is undesirable for cas. So I left the
I literally meant it is not supposed to exist. There was a suggestion to even
axe it from 2.056 I believe.
A library solution is intended to be created which will allow for the type to
act as either a parent or child to the type.
On 31.10.2011 09:34, Manu wrote:
in std? what's the story with core? is it being deprecated?
I would think that cpuid should be a subset of a generalised sysinfo (or
processorinfo perhaps)... something you can optionally obtain if you
first identify that you're on an x86.
Why would there be a
On 10/31/11 8:20 AM, Steven Schveighoffer wrote:
Why doesn't that simple search work?
foreach (line; stdin.byLine()) {
if (line.canFind(fiancé)) {
writeln(There it is.);
}
}
I think Jonathan answered that quite well, nothing else to add...
I see this as a decoding primitive issue that can
Kenji Hara (and the D community) is really good, he has already written a pull
request with the bug fix:
https://github.com/D-Programming-Language/dmd/pull/483
-
Kenji Hara has fixed about 1/3 of the issue, so he asked me to split the but
report, this is a spin off:
I literally meant it is not supposed to exist. There was a suggestion to
even axe it from 2.056 I believe.
At least they prepared to actually deprecate it.
A library solution is intended to be created which will allow for the
type to act as either a parent or child to the type.
On Mon, 31 Oct 2011 17:39:57 +, Steve Teale wrote:
On Mon, 31 Oct 2011 07:58:11 -0500, Andrei Alexandrescu wrote:
On 10/31/11 4:43 AM, Steve Teale wrote:
Is there a way to do this. For example if I have
struct A { int a, b, c; }
struct B
{
int p, q, r, s;
this(A a) { p =
On 10/31/2011 08:34 PM, bearophile wrote:
Kenji Hara (and the D community) is really good, he has already written a pull
request with the bug fix:
https://github.com/D-Programming-Language/dmd/pull/483
-
Kenji Hara has fixed about 1/3 of the issue, so he asked me to split
On 10/31/2011 02:49 AM, bearophile wrote:
Timon Gehr:
A lot of C's carefully designed syntactic elegance is
lost when going from pointers/iterators to arrays and ranges.
I think that a large part of that C syntactic elegance is an illusion. From my
experience, I want my code to look very
On 10/31/11 12:39 PM, Steve Teale wrote:
On Mon, 31 Oct 2011 07:58:11 -0500, Andrei Alexandrescu wrote:
On 10/31/11 4:43 AM, Steve Teale wrote:
Is there a way to do this. For example if I have
struct A { int a, b, c; }
struct B
{
int p, q, r, s;
this(A a) { p = a.a; q = a.b; r =
On Mon, 31 Oct 2011 13:56:21 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sun, 30 Oct 2011 15:23:59 -0400, dsimcha dsim...@yahoo.com wrote:
On 10/30/2011 3:09 PM, Andrei Alexandrescu wrote:
As the opApply body can never be inlined it is a worse choice in
general.
That was
On 10/31/2011 4:16 AM, deadalnix wrote:
Le 31/10/2011 02:21, Mehrdad a écrit :
I've written this piece of code a fair number of times:
static if (is(typeof(foo( { foo(); }
else { bar(); }
When the expression inside the condition (i.e. the call to foo()) gets
complicated, you get lots of
On 10/31/2011 05:41 AM, Steven Schveighoffer wrote:
I encourage anyone to port any portion of dcollections to
std.container. If nothing else it will help flesh out the design of
std.container
Ahem.. No offense, or wth
Maybe I miss the point but I guess you will agree with me that Phobos,
in
On Monday, October 31, 2011 15:47 bls wrote:
On 10/31/2011 05:41 AM, Steven Schveighoffer wrote:
I encourage anyone to port any portion of dcollections to
std.container. If nothing else it will help flesh out the design of
std.container
Ahem.. No offense, or wth
Maybe I miss the point
On 10/31/2011 04:11 PM, Jonathan M Davis wrote:
That's perfectly reasonable. The fact that std.container is so incomplete is a
_huge_ problem for Phobos. It needs to be filled out and its API fully ironed
out. Overall, it looks solid, but it just doesn't have enough actual usage at
this point
Timon Gehr:
Similar code using user-created struct doesn't compile:
struct Foo {
int* p;
size_t n;
}
void main() {
Foo f;
auto x = cast(int*)f; // compile error here
}
That is not similar code. This is:
struct Foo {
size_t length;
int*
On Monday, October 31, 2011 16:48 bls wrote:
On 10/31/2011 04:11 PM, Jonathan M Davis wrote:
That's perfectly reasonable. The fact that std.container is so incomplete
is a _huge_ problem for Phobos. It needs to be filled out and its API
fully ironed out. Overall, it looks solid, but it just
On Mon, 31 Oct 2011 19:21:02 +0200, Vladimir Panteleev wrote:
On Fri, 28 Oct 2011 16:18:27 +0300, dsimcha dsim...@yahoo.com wrote:
Docs:
http://nascent.freeshell.org/programming/D/doc/phobos/std_csv.html
Checked the new docs today. If I'm reading them right, the top example
prints:
On Tuesday, November 01, 2011 01:28:07 Jesse Phillips wrote:
On Mon, 31 Oct 2011 19:21:02 +0200, Vladimir Panteleev wrote:
On Fri, 28 Oct 2011 16:18:27 +0300, dsimcha dsim...@yahoo.com wrote:
Docs:
http://nascent.freeshell.org/programming/D/doc/phobos/std_csv.html
Checked the new docs
On Mon, 31 Oct 2011 19:13:57 +0100, Michel Fortin
michel.for...@michelf.com wrote:
On 2011-10-31 17:07:31 +, Sean Kelly s...@invisibleduck.org said:
writeThis really shouldn't be const, it should be shared. The problem
was t
hat making writeThis a shared pass by value param implied a
On Mon, Oct 31, 2011 at 7:46 PM, Jonathan M Davis jmdavisp...@gmx.comwrote:
On Monday, October 31, 2011 16:48 bls wrote:
On 10/31/2011 04:11 PM, Jonathan M Davis wrote:
That's perfectly reasonable. The fact that std.container is so
incomplete
is a _huge_ problem for Phobos. It needs to
On 10/31/2011 10:13 PM, Michel Fortin wrote:
On 2011-10-31 17:07:31 +, Sean Kelly s...@invisibleduck.org said:
writeThis really shouldn't be const, it should be shared. The problem
was t
hat making writeThis a shared pass by value param implied a
synchronized loa
d for writeThis, which is
On Monday, October 31, 2011 20:57:04 Caligo wrote:
How long before custom allocator stuff is complete? 6 months? a year?
I don't know. I'd expect it to be within the next few months, but there's no
way to know when. I could be sooner; it could be later.
- Jonathan M Davis
Thanks for the explanation guys. That definitely makes me feel better
about using ranges in my code (though for plain iteration opApply does
seem easier to implement due to not forcing to conform to a specific
naming convention except for one operator). When replacing modulus 2
with modulus
On Monday, October 31, 2011 20:08:52 Jonathan M Davis wrote:
On Monday, October 31, 2011 20:57:04 Caligo wrote:
How long before custom allocator stuff is complete? 6 months? a year?
I don't know. I'd expect it to be within the next few months, but there's no
way to know when. I could be
OK, I stand corrected
Steve
Jonathan M Davis wrote:
find allows
you to do that just fine, and such a remove function would simply be
duplicating its functionality.
But this thread serves as a proof that it is not obvious and something like
containers should be obvious to use. Deleting an element with a certain
value
On 31.10.2011 11:16, Tobias Pankrath wrote:
Jonathan M Davis wrote:
find allows
you to do that just fine, and such a remove function would simply be
duplicating its functionality.
But this thread serves as a proof that it is not obvious and something like
containers should be obvious to
On Monday, October 31, 2011 13:16:11 Dmitry Olshansky wrote:
On 31.10.2011 11:16, Tobias Pankrath wrote:
Jonathan M Davis wrote:
find allows
you to do that just fine, and such a remove function would simply be
duplicating its functionality.
But this thread serves as a proof that
Le Sun, 30 Oct 2011 16:44:20 -0400, Nick Sabalausky a écrit :
Frédéric Galusik fr...@salixosnospam.org wrote in message
news:j8j77l$pfv$1...@digitalmars.com...
Hi,
Can someone give me a clue on why nothing is printed to stdout ?
I wish a list of files with their size.
code:
//
import
Le Mon, 31 Oct 2011 00:55:58 +0400, Dmitry Olshansky a écrit :
On 30.10.2011 14:00, Frédéric Galusik wrote:
Hi,
Can someone give me a clue on why nothing is printed to stdout ?
I wish a list of files with their size.
code:
//
import std.stdio;
import std.file;
void main(string[]
On Mon, 31 Oct 2011 06:01:05 -0400, Frédéric Galusik
fr...@salixosnospam.org wrote:
Le Mon, 31 Oct 2011 00:55:58 +0400, Dmitry Olshansky a écrit :
On 30.10.2011 14:00, Frédéric Galusik wrote:
Hi,
Can someone give me a clue on why nothing is printed to stdout ?
I wish a list of files with
On 31.10.2011 18:38, Steven Schveighoffer wrote:
On Mon, 31 Oct 2011 05:16:11 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 31.10.2011 11:16, Tobias Pankrath wrote:
Jonathan M Davis wrote:
find allows
you to do that just fine, and such a remove function would simply be
duplicating
Looks like it was accidental cross-posting:
On 31.10.2011 20:11, Alessandro Stamatto wrote:
it still would be horribly slow O(N^2).
Personally, because of that I'd prefer hand-rolled intrusive
singly-linked list any time of day.
Now you're scaring me... You're saying that
it still would be horribly slow O(N^2).
Personally, because of that I'd prefer hand-rolled intrusive
singly-linked list any time of day.
Now you're scaring me... You're saying that SList in D not only is bugged,
but
a templated remove_if would run in O(N^2) instead of O(N)
On Mon, 31 Oct 2011 12:40:37 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 31.10.2011 18:38, Steven Schveighoffer wrote:
On Mon, 31 Oct 2011 05:16:11 -0400, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 31.10.2011 11:16, Tobias Pankrath wrote:
Jonathan M Davis wrote:
find
Andrej Mitrovic:
Otherwise if you want to use the GC there's no point in calling
GC.free in the destructor since the GC will do that automatically.
And if the OP wants some determinism in the dellocation of the memory allocated
with malloc, the OP has to use a struct (scope classes used to
http://d.puremagic.com/issues/show_bug.cgi?id=3990
--- Comment #3 from Kenji Hara k.hara...@gmail.com 2011-10-31 04:30:21 PDT ---
(In reply to comment #0)
1.
assert(*a1 == 5);
alias typeof(a1) T1;
assert(is(typeof(*T1)));
Dereferencing dynamic or static array without -d option is
http://d.puremagic.com/issues/show_bug.cgi?id=3990
--- Comment #4 from Kenji Hara k.hara...@gmail.com 2011-10-31 04:33:36 PDT ---
(In reply to comment #1)
This is not related.
auto p = new Arr!(10);
*p = 10;
means
Arr!(10)* p = new Arr!(10);
(*p).data = 10; // see alias this
http://d.puremagic.com/issues/show_bug.cgi?id=3990
--- Comment #5 from bearophile_h...@eml.cc 2011-10-31 05:36:43 PDT ---
(In reply to comment #3)
assert(*a1 == 5);
alias typeof(a1) T1;
assert(is(typeof(*T1)));
Dereferencing dynamic or static array without -d option is
http://d.puremagic.com/issues/show_bug.cgi?id=3990
--- Comment #6 from bearophile_h...@eml.cc 2011-10-31 05:39:53 PDT ---
(In reply to comment #4)
This is not related.
You are right, it's not related, it's a different problem.
And, the assignment an element type into static array is
http://d.puremagic.com/issues/show_bug.cgi?id=3990
--- Comment #7 from Kenji Hara k.hara...@gmail.com 2011-10-31 07:43:01 PDT ---
(In reply to comment #5)
I don't see the need to accept this cast. There is the .ptr so this cast is
not useful in practice. And generally this cast is refused by
http://d.puremagic.com/issues/show_bug.cgi?id=3990
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||patch
--- Comment #8
http://d.puremagic.com/issues/show_bug.cgi?id=3757
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
Keywords|spec|wrong-code
http://d.puremagic.com/issues/show_bug.cgi?id=6864
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=6865
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=6866
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=6867
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=6869
Summary: Disallow array to pointer cast
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
http://d.puremagic.com/issues/show_bug.cgi?id=3990
--- Comment #9 from bearophile_h...@eml.cc 2011-10-31 12:24:36 PDT ---
(In reply to comment #7)
Thank you for the patch.
The title of this issue is Deferencing a dynamic array as pointer.
Therefore even if you think it is not useful, we
http://d.puremagic.com/issues/show_bug.cgi?id=6869
--- Comment #1 from bearophile_h...@eml.cc 2011-10-31 17:38:33 PDT ---
See some discussion:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=148090
An answer:
86 matches
Mail list logo
