Why does a Windows version require building anyway? Building
stuff is for Linux people, because they love to hunt dependencies
and stuff. On Windows you should be able to unzip an archive or
use an installer and have two directories - include files and
compiled .lib/.a/.dll libraries ready to
On Wednesday, 3 October 2012 at 21:40:06 UTC, Timon Gehr wrote:
On 10/03/2012 05:59 PM, renoX wrote:
I have some mixed feeling about component programming: add in
all the
examples the requirement to give the context (line number for
example)
where something happened (either a match or an
I would like to share with you, Beta version of
http://dpaste.dzfl.pl/
This is a great tool!
Optional VIM-like navigation would make it even better.
On 10/04/2012 01:05 PM, JN wrote:
Why does a Windows version require building anyway? Building stuff is
for Linux people, because they love to hunt dependencies and stuff. On
Windows you should be able to unzip an archive or use an installer and
have two directories - include files and compiled
On 10/04/2012 02:32 AM, Tommi wrote:
On Wednesday, 26 September 2012 at 18:48:41 UTC, Mike James wrote:
I tried the install detailed on the github page and got the following
error:
C:\D\dmd2\gtkD2\srcdgen
build\gtkD.d(612): Error: module SourceBuffer is in file
'gsv\SourceBuffer.d' wh
ich
On Thursday, 4 October 2012 at 05:18:20 UTC, Walter Bright wrote:
I wish to point out that order doesn't necessarily matter with
a range, so there is not a 1:1 correspondence with a sequence.
For example, the ordering of elements in an associative array
is arbitrary.
Oh, right. I guess in
On Wednesday, 3 October 2012 at 23:38:57 UTC, Alex Rønne
Petersen wrote:
1. precise
Yes. Work is being done.
BTW, where can I learn about the current progress with GC? Is
this work concentrated in one project or are there several
parallel works on improving GC? Is anyone already working on
On 2012-10-04 07:12, Walter Bright wrote:
I wish to point out that order doesn't necessarily matter with a range,
so there is not a 1:1 correspondence with a sequence.
For example, the ordering of elements in an associative array is arbitrary.
Only if it's uses a hash implementation, which
On 2012-10-04 00:01, DypthroposTheImposter wrote:
Did that hook thing to let peoples write custom GC ever make it in?
Yes, it's pluggable at link time. Here's an example of a stub
implementation:
http://www.dsource.org/projects/tango/browser/trunk/tango/core/rt/gc/stub
It's for Tango but
On Wednesday, October 03, 2012 22:13:10 Walter Bright wrote:
I kinda thought they should have been called sources and sinks, but
I think it's too late for that.
Yes, but if we think that it's enough of an improvement, we could probably
start naming parameters to range-based functions with
On 2012-10-04 08:01, thedeemon wrote:
BTW, where can I learn about the current progress with GC? Is
this work concentrated in one project or are there several
parallel works on improving GC? Is anyone already working on
making memory allocation and GC more multicore friendly?
If I recall
On 2012-10-04 01:33, Alex Rønne Petersen wrote:
Use tuples. Multiple return values (as far as ABI goes) are impractical
because every major compiler back end (GCC, LLVM, ...) would have to be
adjusted for every architecture.
Why can't it just be syntax sugar for returning a struct?
--
/Jacob
A couple weeks ago, an issue came up regarding parse's behavior
in regards to skipping leading ws.
http://d.puremagic.com/issues/show_bug.cgi?id=8729
https://github.com/D-Programming-Language/phobos/pull/817
https://github.com/D-Programming-Language/phobos/pull/828
The gist of the
On Thu, 2012-10-04 at 05:05 +0200, Alex Rønne Petersen wrote:
[…]
Look, not to sound dismissive, but D3 is not a thing and likely will
never be.
D v3 will come if it comes. Implying D3 will never happen is, I believe,
the wrong sort of impression to put out onto the interwebs; it implies
that
Am 10/4/2012 10:48 AM, schrieb monarch_dodra:
A couple weeks ago, an issue came up regarding parse's behavior in
regards to skipping leading ws.
http://d.puremagic.com/issues/show_bug.cgi?id=8729
https://github.com/D-Programming-Language/phobos/pull/817
On 02/10/12 17:14, Andrei Alexandrescu wrote:
On 10/2/12 7:11 AM, Don Clugston wrote:
The problem
---
String literals in D are a little bit magical; they have a trailing \0.
[snip]
I don't mean to be Debbie Downer on this because I reckon it addresses
an issue that some have,
On Tuesday, 2 October 2012 at 15:14:10 UTC, Andrei Alexandrescu
wrote:
First, I think zero-terminated strings shouldn't be needed
frequently enough in D code to make this necessary.
My experience has been much different. Interfacing with C occurs
in nearly every D program I write, and I
On Thursday, 4 October 2012 at 07:57:16 UTC, Bernard Helyer wrote:
On Tuesday, 2 October 2012 at 15:14:10 UTC, Andrei Alexandrescu
wrote:
First, I think zero-terminated strings shouldn't be needed
frequently enough in D code to make this necessary.
My experience has been much different.
On Tuesday, 2 October 2012 at 01:00:25 UTC, Walter Bright wrote:
Since all you need to do to guarantee compile time evaluation
is use it in a context that requires CTFE, which are exactly
the cases where you'd care that it was CTFE'd, I just don't see
much utility here.
I suppose the most
On Tuesday, 2 October 2012 at 13:07:46 UTC, deadalnix wrote:
Le 01/10/2012 22:33, Vladimir Panteleev a écrit :
On Monday, 1 October 2012 at 12:12:52 UTC, deadalnix wrote:
Le 01/10/2012 13:29, Vladimir Panteleev a écrit :
On Monday, 1 October 2012 at 10:56:36 UTC, deadalnix wrote:
How does
I'm trying to find out the exact semantics of
@disable this();
It is not well documented, and the fact that it is (supposedly)
buggy makes it really confusing.
My understanding is that it merely makes it illegal to default
initialization your type: You, the developer, have to specify the
On Tuesday, 2 October 2012 at 14:03:36 UTC, monarch_dodra wrote:
If you want 0 termination, then make it explicit, that's my
opinion.
That ship has long since sailed. You'll break code in an
incredibly dangerous way if you were to change it now.
On Thursday, October 04, 2012 10:18:14 monarch_dodra wrote:
Making it illegal would pretty much make T unmoveable,
un-emplaceable, un-initializeable on un-initialized memmory,
That's kind of the point. If that's not what you want, don't disable init.
and
would probably break more than one
On Thursday, 4 October 2012 at 09:25:01 UTC, Jonathan M Davis
wrote:
On Thursday, October 04, 2012 10:18:14 monarch_dodra wrote:
Making it illegal would pretty much make T unmoveable,
un-emplaceable, un-initializeable on un-initialized memmory,
That's kind of the point. If that's not what you
One of the issues I've been running into more or less frequently
lately is the inability to extract an instance of a type when
trying to do conditional implementation specification.
Let me explain myself. Using T.init is a no go, because:
a) T might be @disabled this(), making T.init illegal
On 04-10-2012 08:50, Jacob Carlborg wrote:
On 2012-10-04 01:33, Alex Rønne Petersen wrote:
Use tuples. Multiple return values (as far as ABI goes) are impractical
because every major compiler back end (GCC, LLVM, ...) would have to be
adjusted for every architecture.
Why can't it just be
On 04-10-2012 08:49, Jacob Carlborg wrote:
On 2012-10-04 00:01, DypthroposTheImposter wrote:
Did that hook thing to let peoples write custom GC ever make it in?
Yes, it's pluggable at link time. Here's an example of a stub
implementation:
On Thu, 04 Oct 2012 01:05:14 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Wed, 03 Oct 2012 08:37:14 -0400, Regan Heath re...@netmail.co.nz
wrote:
On Tue, 02 Oct 2012 21:44:11 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
In fact, a better solution would be to define
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright
wrote:
On 9/15/2012 5:39 AM, Henning Pohl wrote:
The way D is dealing with classes reminds me of pointers
because you can null
them. C++'s references cannot (of course you can do some nasty
casting).
Doing null references in C++
On Thu, 2012-10-04 at 03:49 +0200, Jesse Phillips wrote:
[…]
So, you are saying that these examples are exhibiting the same
problems because they are based on the same design?
I don't see how that would invalidate the results. That is, I
don't see the relevance here.
My comment relates to
Timon Gehr:
To quote (loosely) Mr. Walter Bright from another discussion:
how many
current bugs in dmd are related to default null references?
More than zero.
A 0 frequency of bugs caused by something can't be enough to
justify a language feature. You need a high enough frequency :-)
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of OS threads, which is great.
However, what is *not* great is that spawned tasks correspond 1:1 to OS
threads. This is not even remotely scalable for Erlang-style
concurrency. There's
On Thursday, 4 October 2012 at 09:43:08 UTC, monarch_dodra wrote:
[SNIP]
You know what? Forget I said anything? Using lambdas is an
incredibly good workaround for all the problems stated above,
making the initial point moot.
Lamba if:
template isAssignable(T, U)
{
enum bool
On 2012-10-04 12:58, Alex Rønne Petersen wrote:
More relevant to D2:
https://github.com/D-Programming-Language/druntime/tree/master/src/gcstub
(Though admittedly nobody has built it for a while - so, disclaimer:
there may be some silly build errors if you try to build it, but they
should be
On 10/04/2012 01:32 PM, Alex Rønne Petersen wrote:
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of OS threads, which is great.
However, what is *not* great is that spawned tasks correspond 1:1 to OS
threads. This is not even
On Thursday, 4 October 2012 at 09:43:08 UTC, monarch_dodra wrote:
The current implementation for isAssignable is
//
template isAssignable(Lhs, Rhs)
{
enum bool isAssignable = is(typeof({
Lhs l = void;
void f(Rhs r) { l = r; }
return l;
}));
}
OT - Is there
On 04-10-2012 14:11, Timon Gehr wrote:
On 10/04/2012 01:32 PM, Alex Rønne Petersen wrote:
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of OS threads, which is great.
However, what is *not* great is that spawned tasks correspond 1:1
On 10/04/2012 02:22 PM, Alex Rønne Petersen wrote:
On 04-10-2012 14:11, Timon Gehr wrote:
On 10/04/2012 01:32 PM, Alex Rønne Petersen wrote:
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of OS threads, which is great.
However, what
On Thursday, 4 October 2012 at 12:48:51 UTC, so wrote:
On Thursday, 4 October 2012 at 09:43:08 UTC, monarch_dodra
wrote:
The current implementation for isAssignable is
//
template isAssignable(Lhs, Rhs)
{
enum bool isAssignable = is(typeof({
Lhs l = void;
void f(Rhs r) {
On 2012-10-04 12:59, Alex Rønne Petersen wrote:
I agree that it should be, FWIW. The problem is that some people really
expect the ABI to be altered, which is unrealistic.
Is there an advantage of altering the ABI?
--
/Jacob Carlborg
On 04-10-2012 14:26, Jacob Carlborg wrote:
On 2012-10-04 12:59, Alex Rønne Petersen wrote:
I agree that it should be, FWIW. The problem is that some people really
expect the ABI to be altered, which is unrealistic.
Is there an advantage of altering the ABI?
Presumably speed; returning
On 10/04/2012 01:38 PM, bearophile wrote:
Timon Gehr:
To quote (loosely) Mr. Walter Bright from another discussion: how many
current bugs in dmd are related to default null references?
More than zero.
A 0 frequency of bugs caused by something can't be enough to justify a
language feature.
On 04-10-2012 14:48, Timon Gehr wrote:
On 10/04/2012 02:22 PM, Alex Rønne Petersen wrote:
On 04-10-2012 14:11, Timon Gehr wrote:
On 10/04/2012 01:32 PM, Alex Rønne Petersen wrote:
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of
On 2012-10-04 14:36, Alex Rønne Petersen wrote:
Presumably speed; returning small structs in registers will be faster
than doing so on the stack.
Are sturcts currently always returned on the stack?
But I don't agree that the vast complexity of altering well-established
ABIs for multiple
On 04-10-2012 15:21, Piotr Szturmaj wrote:
Jacob Carlborg wrote:
On 2012-10-04 14:36, Alex Rønne Petersen wrote:
Presumably speed; returning small structs in registers will be faster
than doing so on the stack.
Are sturcts currently always returned on the stack?
From:
Jacob Carlborg wrote:
On 2012-10-04 14:36, Alex Rønne Petersen wrote:
Presumably speed; returning small structs in registers will be faster
than doing so on the stack.
Are sturcts currently always returned on the stack?
From: http://dlang.org/abi.html, for Windows x86 extern(D):
* 1, 2
On 04-10-2012 15:06, Jacob Carlborg wrote:
On 2012-10-04 14:36, Alex Rønne Petersen wrote:
Presumably speed; returning small structs in registers will be faster
than doing so on the stack.
Are sturcts currently always returned on the stack?
As always, it depends on the arch, but on 32-bit
I wonder if tuple should automatically expand (flatten) into a
list of arguments not only when used with template parameters,
but with regular functions as well. This so, that it would enable
composition of tuple returning functions with functions that take
in individual arguments instead of a
On Wednesday, 3 October 2012 at 23:02:25 UTC, dsimcha wrote:
So the process which creates the future is a Task that
executes in a different thread than the caller? And an
alternative way that a value might become available in the
future is e.g. if it's being retrieved from some slow I/O
On 10/4/12, monarch_dodra monarchdo...@gmail.com wrote:
I'm trying to find out the exact semantics of
@disable this();
Also this still works:
struct Foo
{
@disable this();
}
void main()
{
Foo foo = Foo();
}
I really don't know why though.. Isn't this a bug? A workaround in
user-code
2012/10/4 monarch_dodra monarchdo...@gmail.com:
One of the issues I've been running into more or less frequently lately is
the inability to extract an instance of a type when trying to do conditional
implementation specification.
Let me explain myself. Using T.init is a no go, because:
a) T
On Thursday, 4 October 2012 at 17:37:58 UTC, Andrej Mitrovic
wrote:
On 10/4/12, monarch_dodra monarchdo...@gmail.com wrote:
I'm trying to find out the exact semantics of
@disable this();
Also this still works:
struct Foo
{
@disable this();
}
void main()
{
Foo foo = Foo();
}
I
On Thursday, 4 October 2012 at 17:44:48 UTC, kenji hara wrote:
a) T might be @disabled this(), making T.init illegal syntax
(in theory,
currently buggy)
I think T.init should always legal.
What would be the semantics of T.init for a type with @disable
this()? It isn't a valid value, for
On Thursday, October 04, 2012 13:14:00 Alex Burton, @gmail.com wrote:
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright
wrote:
On 9/15/2012 5:39 AM, Henning Pohl wrote:
The way D is dealing with classes reminds me of pointers
because you can null
them. C++'s references
On 2012-37-04 11:10, monarch_dodra monarchdo...@gmail.com wrote:
One of the issues I've been running into more or less frequently lately
is the inability to extract an instance of a type when trying to do
conditional implementation specification.
Let me explain myself. Using T.init is a no
On 10/04/2012 05:16 PM, Tommi wrote:
I wonder if tuple should automatically expand (flatten) into a list of
arguments not only when used with template parameters, but with regular
functions as well. This so, that it would enable composition of tuple
returning functions with functions that take
On 2012-40-04 00:10, Tommi tommitiss...@hotmail.com wrote:
(tuples automatically expand if needed)
False. Typetuples do, but those cannot be returned from functions.
--
Simen
On 2012-27-04 07:10, Walter Bright newshou...@digitalmars.com wrote:
* OpCmp returning an int is fugly I r sad
How else would you return a 3 state value?
enum Comparison {
Before = -1,
Same = 0,
After = 1,
Unordered = NaN,
}
I'm not saying it should be done, but it would be
Ok, I think I see where you're coming from here. I've replied to
some points below just to make sure and discuss possible
solutions.
On Thursday, 4 October 2012 at 16:07:35 UTC, David Nadlinger
wrote:
On Wednesday, 3 October 2012 at 23:02:25 UTC, dsimcha wrote:
Because you already have a
On Thursday, 4 October 2012 at 18:12:09 UTC, Timon Gehr wrote:
void main(){
fun(getTuple().expand);
}
Great, that works for me. It would be probably confusing if they
tuples expanded automatically; non-obvious if you'd be passing
one argument or multiple.
2012/10/4 monarch_dodra monarchdo...@gmail.com:
I'm trying to find out the exact semantics of
@disable this();
It is not well documented, and the fact that it is (supposedly) buggy makes
it really confusing.
My understanding is that it merely makes it illegal to default
initialization
On 2012-10-04, 20:56, Tommi wrote:
On Thursday, 4 October 2012 at 18:12:09 UTC, Timon Gehr wrote:
void main(){
fun(getTuple().expand);
}
Great, that works for me. It would be probably confusing if they tuples
expanded automatically; non-obvious if you'd be passing one argument or
On Wednesday, 3 October 2012 at 21:31:52 UTC,
DypthroposTheImposter wrote:
D is pretty cool, perhaps someday I can use it instead of C++
and have cool shit like fast build times, modules, no more
bloody headers, sane templates, CTFE, UFCS etc
But can the D GC ever be made:
1. precise
2.
On 04-Oct-12 15:32, Alex Rønne Petersen wrote:
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of OS threads, which is great.
However, what is *not* great is that spawned tasks correspond 1:1 to OS
threads. This is not even remotely
On 04-Oct-12 16:48, Timon Gehr wrote:
On 10/04/2012 02:22 PM, Alex Rønne Petersen wrote:
On 04-10-2012 14:11, Timon Gehr wrote:
[snip]
I think that no matter what we do, we have to simply say don't do that
to thread-local state (it would break in distributed scenarios too, for
instance).
On Thursday, October 04, 2012 13:32:01 Alex Rønne Petersen wrote:
Thoughts? Other ideas?
std.concurrency is supposed to be designed such that it can be used for more
than just threads (e.g. sending messages across the network), so if it needs
to be adjusted to accomodate that, then we should
On Thursday, 4 October 2012 at 17:57:51 UTC, Simen Kjaeraas wrote:
[SNIP]
@property T instanceOf( T )( );
[SNIP]
Awesome! It is much more robust too! I still don't understand how
*my* instanceOf!(immutable(S)) works :/
I'd just change it to:
@property ref T instanceOf( T )( );
So that
Could you change it so that expressions, that are separated by
commas and inside an if-clause, would have visibility to the
variable defined in the first expression? Easier to show than to
explain:
int getInt()
{
return 11;
}
void main()
{
if (int n = getInt(), n 10) // undefined
On Thursday, 4 October 2012 at 21:17:51 UTC, Tommi wrote:
Could you change it so that expressions, that are separated by
commas and inside an if-clause, would have visibility to the
variable defined in the first expression? Easier to show than
to explain:
[SNIP]
A language change sounds
On Thursday, October 04, 2012 23:11:58 Tommi wrote:
Could you change it so that expressions, that are separated by
commas and inside an if-clause, would have visibility to the
variable defined in the first expression? Easier to show than to
explain:
int getInt()
{
return 11;
}
void
On Thursday, 4 October 2012 at 21:32:34 UTC, Jonathan M Davis
wrote:
If you want to restrict the scope of a variable, you can simply
use another set of braces to create a new scope. It might be
more verbose than desirable, but it works just fine. e.g.
{
int n = getInt();
if(n 10)
{
...
On Thursday, 4 October 2012 at 21:17:51 UTC, Tommi wrote:
Could you change it so that expressions, that are separated by
commas and inside an if-clause, would have visibility to the
variable defined in the first expression?
Yes, a language designed could make that choice. But not, it
On Thursday, 4 October 2012 at 22:28:24 UTC, David Nadlinger
wrote:
Yes, a language designed could make that choice. But not, it
certainly won't be considered for D unless it can be shown that
the change solves a real problem with the current syntax.
But I'm not suggesting any kind of
On Thursday, 4 October 2012 at 22:28:24 UTC, David Nadlinger
wrote:
how often have you really encountered big syntactic headaches
because of not having something like this available?
I do somewhat regularly. The if(auto x = y()) { use x } is pretty
convenient but being limited only to the
On Thursday, 4 October 2012 at 16:07:35 UTC, David Nadlinger
wrote:
For more advanced/application-level use cases, just look at any
use of ContinueWith in C#. std::future::then() is also proposed
for C++, see e.g.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3327.pdf.
I didn't
On Thursday, 4 October 2012 at 22:36:47 UTC, Tommi wrote:
But I'm not suggesting any kind of change in syntax. This
syntax in D currently works (as long as expr2 is convertible to
bool):
if (Type var = expr1, expr2)
{
//...
}
What I'm suggesting is, I think, quite reasonable: make it so
On Thursday, 4 October 2012 at 23:16:53 UTC, Tommi wrote:
Didn't see that coming. But I think it might be a bug, because
assignment expression has precedence over sequencing
expression, that is, expressions separated by commas.
Although that's not an assignment expression, but a variable
On Oct 4, 2012, at 4:32 AM, Alex Rønne Petersen a...@lycus.org wrote:
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of OS threads, which is great. However,
what is *not* great is that spawned tasks correspond 1:1 to OS threads.
On Oct 4, 2012, at 5:48 AM, Timon Gehr timon.g...@gmx.ch wrote:
What about the stack? Allocating a fixed-size stack per task is costly
and Walter opposes dynamic stack growth.
This is another reason I've been delaying using fibers. The correct approach
is probably to go the distance by
On Thursday, October 04, 2012 23:56:15 Tommi wrote:
As it stands, there's a good chance that the comma operator is
actually going to be _removed_ from the language (aside from
specific use cases such as inside for loops). So, I don't think
that there's much chance of it being expanded at
Maybe we forget about commas then, and extend if-clauses so that
you can properly define variables at the beginning of it.
Separated by semicolons.
string name;
if (string street = nextStreet();
int number = nextNumber();
auto person = new Person(name);
person.livesAt(number,
On Friday, October 05, 2012 00:36:22 Adam D. Ruppe wrote:
On Thursday, 4 October 2012 at 22:28:24 UTC, David Nadlinger
wrote:
how often have you really encountered big syntactic headaches
because of not having something like this available?
I do somewhat regularly. The if(auto x = y())
Tommi:
Maybe we forget about commas then, and extend if-clauses so
that you can properly define variables at the beginning of it.
Separated by semicolons.
Regarding definition of variables in D language constructs, there
is one situation where sometimes I find D not handy. This code
can't
On Friday, October 05, 2012 02:08:14 bearophile wrote:
Tommi:
Maybe we forget about commas then, and extend if-clauses so
that you can properly define variables at the beginning of it.
Separated by semicolons.
Regarding definition of variables in D language constructs, there
is one
Is the plan to deprecate comma operator for chaining expressions?
I would love to see more syntactic sugar to support tuples, and
comma operator would be the best fit for that purpose.
eg:
import std.typecons;
auto fun(){
return tuple(1,abc);
//1) ideally, we should be able to
On Friday, October 05, 2012 02:33:45 timotheecour wrote:
Is the plan to deprecate comma operator for chaining expressions?
That's all the comma operator does. If it's not chaining expressions, it's not
the comma operator (e.g. variables declarations do _not_ use the comma
operator even though
On 10/3/2012 11:50 PM, Jacob Carlborg wrote:
On 2012-10-04 01:33, Alex Rønne Petersen wrote:
Use tuples. Multiple return values (as far as ABI goes) are impractical
because every major compiler back end (GCC, LLVM, ...) would have to be
adjusted for every architecture.
Why can't it just be
Le 04/10/2012 10:18, monarch_dodra a écrit :
I'm trying to find out the exact semantics of
@disable this();
It is not well documented, and the fact that it is (supposedly) buggy
makes it really confusing.
My understanding is that it merely makes it illegal to default
initialization your type:
Le 04/10/2012 13:32, Alex Rønne Petersen a écrit :
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of OS threads, which is great.
However, what is *not* great is that spawned tasks correspond 1:1 to OS
threads. This is not even
Ideally,
struct S { int a; int b; }
void foo(int p, int q);
S s;
foo(s);
should work (setting aside for the moment that they are
different types). Unfortunately, the variety of function
calling ABIs makes this impractical.
So tuples in a language like D that must conform to
On Thursday, 4 October 2012 at 17:55:45 UTC, Jonathan M Davis
wrote:
On Thursday, October 04, 2012 13:14:00 Alex Burton, @gmail.com
wrote:
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright
wrote:
On 9/15/2012 5:39 AM, Henning Pohl wrote:
The way D is dealing with classes reminds
On Wednesday, 3 October 2012 at 17:37:14 UTC, Franciszek Czekała
wrote:
On Wednesday, 3 October 2012 at 16:33:15 UTC, Simen Kjaeraas
wrote:
On 2012-10-03, 18:12, wrote:
They make sure you never pass null to a function that doesn't
expect null - I'd say that's a nice advantage.
However
On Saturday, 15 September 2012 at 17:51:39 UTC, Jonathan M Davis
wrote:
On Saturday, September 15, 2012 19:35:44 Alex Rønne Petersen
wrote:
Out of curiosity: Why? How often does your code actually
accept null as
a valid state of a class reference?
I have no idea. I know that it's a
On 05-10-2012 04:14, deadalnix wrote:
Le 04/10/2012 13:32, Alex Rønne Petersen a écrit :
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of OS threads, which is great.
However, what is *not* great is that spawned tasks correspond 1:1
On 05-10-2012 01:30, Sean Kelly wrote:
On Oct 4, 2012, at 4:32 AM, Alex Rønne Petersen a...@lycus.org wrote:
Hi,
We currently have std.concurrency as a message-passing mechanism. We encourage
people to use it instead of OS threads, which is great. However, what is *not*
great is that
On 05-10-2012 01:34, Sean Kelly wrote:
On Oct 4, 2012, at 5:48 AM, Timon Gehr timon.g...@gmx.ch wrote:
What about the stack? Allocating a fixed-size stack per task is costly
and Walter opposes dynamic stack growth.
This is another reason I've been delaying using fibers. The correct approach
On 04-10-2012 22:04, Dmitry Olshansky wrote:
On 04-Oct-12 15:32, Alex Rønne Petersen wrote:
Hi,
We currently have std.concurrency as a message-passing mechanism. We
encourage people to use it instead of OS threads, which is great.
However, what is *not* great is that spawned tasks correspond
On Friday, October 05, 2012 05:42:03 Alex Burton wrote:
I realise what is currently the case I am making an argument as
to why I this should be changed (at least for class references in
D).
This was talking about C++ references, not D, giving an example of how they
can be null even though
This code (rightfully) generates an error:
int[] f(int[] args...) {
return args;
}
However, this code doesn't generate any warning or error:
import std.conv;
import std.stdio;
class C {
real[] val;
On 2012-10-03 23:51, timotheecour wrote:
In my case I can't: I don't have control over the main function (it
could be written in C for example).
If you're developing a library or similar you could have a requirement
that the user need to call Library.initialize() before use. But of
course,
1 - 100 of 168 matches
Mail list logo
