On Friday, 15 August 2014 at 12:49:37 UTC, Paulo Pinto wrote:
So is the cost of trying not to have an healthy set of
libraries as part of the standard like the other programming
languages. Thanks to the C tradition that the language library
is the OS.
Thankfully, the standard is now catching
Am 11.08.2014 13:02, schrieb Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com:
I think dataflow in combination with transactional memory (Haswell and
newer CPUs) could be a killer feature.
FYI: Intel TSX is not a thing anymore, it turned out to be buggy and is
disabled by a microcode
On Monday, 11 August 2014 at 15:42:17 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 11 August 2014 at 15:13:43 UTC, Russel Winder via ...
C++ is good example of the high eco system costs of trying to
support everything, but very little out of the box. You
basically have to select one primary
On Sunday, 10 August 2014 at 10:00:45 UTC, Russel Winder via
Digitalmars-d wrote:
So if D got CSP, it would be me too but useful. If D got
dataflow it
would be D the first language to support dataflow in native
code
systems. Now that could sell.
Yes, that would be cool, but what do you mean
On Mon, 2014-08-11 at 11:02 +, via Digitalmars-d wrote:
[…]
Yes, that would be cool, but what do you mean specifically with
dataflow? Apparently it is used to describe everything from
tuple spaces to DSP engines.
I guess it is true that tuple spaces can be dataflow systems, as indeed
can
On Monday, 11 August 2014 at 15:13:43 UTC, Russel Winder via
Digitalmars-d wrote:
For me, software dataflow architecture is processes with input
channels
and output channels where the each process only computes on the
receipt
of data ready on some a combination of its inputs.
Yes, but to get
I think Walter is exactly right with the first 7 points he is
listing in his starting post of this thread. Nullable types are
nice, but don't get too much distracted by them. The first 7
points are far more important. Go takes absolutely no effort to
get rid of nil and they are very successful
On Sun, 2014-08-10 at 09:27 +, Bienlein via Digitalmars-d wrote:
[…]
IMHO goroutines and channels is really the key. D might be a
better C++. But languages need a use case to make people change.
From a marketing perspective, Go introduced goroutines (which is an
implementation of a minor
On 14/07/14 18:16, H. S. Teoh via Digitalmars-d wrote:
Mine is here:
http://wiki.dlang.org/User:Quickfur/DIP_scope
From the DIP:
The 'scope' keyword has been around for years, yet it is barely
implemented and it's unclear just what it's supposed to mean
I don't know if it's worth
On 07/15/2014 08:42 AM, Jacob Carlborg wrote:
On 14/07/14 18:16, H. S. Teoh via Digitalmars-d wrote:
Mine is here:
http://wiki.dlang.org/User:Quickfur/DIP_scope
From the DIP:
The 'scope' keyword has been around for years, yet it is barely
implemented and it's unclear just what
On 15/07/14 01:48, H. S. Teoh via Digitalmars-d wrote:
Yes, but since the extent of this scope is unknown from inside the
function body, it doesn't easily lend itself nicely to check things like
this:
int* ptr;
void func(scope int* arg) {
ptr = arg; // should
On 15/07/14 08:46, simendsjo wrote:
Isn't both 1 and 2 deprecated?
Depends on what you mean by deprecated. People are keep saying that
but it's not. Nothing, except for people saying that, indicates that. No
deprecation message, no warning, nothing about it in the documentation.
Even
On Tuesday, 15 July 2014 at 06:42:20 UTC, Jacob Carlborg wrote:
1. Allocate classes on the stack: scope bar = new Bar()
4. Scope parameters. This is the part that is unclear what is
means/is supposed to mean in the current language
These are actually the same thing: if something is stack
On 15/07/14 14:47, Adam D. Ruppe wrote:
These are actually the same thing: if something is stack allocated, it
must not allow the reference to escape to remain memory safe... and if
the reference is not allowed to escape, stack allocating the object
becomes an obvious automatic optimization.
On Tue, Jul 15, 2014 at 09:19:34AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 15/07/14 01:48, H. S. Teoh via Digitalmars-d wrote:
Yes, but since the extent of this scope is unknown from inside the
function body, it doesn't easily lend itself nicely to check things
like this:
On 2014-07-15 16:58, H. S. Teoh via Digitalmars-d wrote:
But what if 'ptr' is declared in a private binary-only module, and only
the signature of 'func' is known? Then what should 'scope' mean to the
compiler when 'func' is being called from another module?
Hmm, I didn't think of that :(
--
On 13/07/14 16:37, H. S. Teoh via Digitalmars-d wrote:
We could, but how would that help static analysis within the function's
body, since the caller's scope is unknown?
Won't the caller's scope always outlive the callee's?
--
/Jacob Carlborg
On Sun, Jul 13, 2014 at 02:58:27PM +, via Digitalmars-d wrote:
On Friday, 11 July 2014 at 22:03:37 UTC, H. S. Teoh via Digitalmars-d wrote:
Maybe what we should do, is to have everyone post their current
(probably incomplete) drafts of what scope should do, so that we have
everything on
On Sunday, 13 July 2014 at 18:20:12 UTC, Walter Bright wrote:
On 7/13/2014 4:05 AM, Dicebot wrote:
Also I was not speaking originally about all good pull
requests just waiting
to be merged but about stuff that hits some controversial
language/Phobos parts
and requires some decision if it can
On 7/14/2014 9:56 AM, Dicebot wrote:
I will keep an eye std.concurrency but I what should I do to convince you say a
word or two about DMD PR that makes some language change? :)
I still believe that Andrei I need to approve language change PRs. These can
be very disruptive and not easily
On Monday, 14 July 2014 at 18:30:34 UTC, Walter Bright wrote:
On 7/14/2014 9:56 AM, Dicebot wrote:
I will keep an eye std.concurrency but I what should I do to
convince you say a
word or two about DMD PR that makes some language change? :)
I still believe that Andrei I need to approve
On 7/14/14, 12:10 PM, Dicebot wrote:
On Monday, 14 July 2014 at 18:30:34 UTC, Walter Bright wrote:
On 7/14/2014 9:56 AM, Dicebot wrote:
I will keep an eye std.concurrency but I what should I do to convince
you say a
word or two about DMD PR that makes some language change? :)
I still believe
On Mon, Jul 14, 2014 at 10:41:10AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 13/07/14 16:37, H. S. Teoh via Digitalmars-d wrote:
We could, but how would that help static analysis within the
function's body, since the caller's scope is unknown?
Won't the caller's scope always
On 7/14/2014 12:10 PM, Dicebot wrote:
On Monday, 14 July 2014 at 18:30:34 UTC, Walter Bright wrote:
For example,
https://issues.dlang.org/show_bug.cgi?id=11946
I mean something like this :
https://github.com/D-Programming-Language/dmd/pull/3651 - change that was
implemented, generally
On 7/10/2014 5:54 AM, Dicebot wrote:
No one but Walter / Andrei can do anything about it. Right now we are in weird
situation when they call for lieutenants but are not ready to abandon decision
power. It can't possibly work that way. No amount of volunteer effort will help
when so many PR stall
On 2014-07-11 16:29, H. S. Teoh via Digitalmars-d wrote:
Because the scope of the parameter 'obj' is defined to be the scope of
myFunc only, according to the current proposal.
Wouldn't it be possible to define the scope of a parameter to the
caller's scope?
--
/Jacob Carlborg
On Sunday, 13 July 2014 at 07:18:53 UTC, Walter Bright wrote:
On 7/10/2014 5:54 AM, Dicebot wrote:
No one but Walter / Andrei can do anything about it. Right now
we are in weird
situation when they call for lieutenants but are not ready
to abandon decision
power. It can't possibly work that
On Sunday, 13 July 2014 at 07:18:53 UTC, Walter Bright wrote:
On 7/10/2014 5:54 AM, Dicebot wrote:
No one but Walter / Andrei can do anything about it. Right now
we are in weird
situation when they call for lieutenants but are not ready
to abandon decision
power. It can't possibly work that
On Sun, Jul 13, 2014 at 12:07:58PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 2014-07-11 16:29, H. S. Teoh via Digitalmars-d wrote:
Because the scope of the parameter 'obj' is defined to be the scope
of myFunc only, according to the current proposal.
Wouldn't it be possible to
On Friday, 11 July 2014 at 22:03:37 UTC, H. S. Teoh via
Digitalmars-d wrote:
Maybe what we should do, is to have everyone post their current
(probably incomplete) drafts of what scope should do, so that
we have
everything on the table and we can talk about what should be
kept, what
should be
On 7/13/2014 3:47 AM, Dicebot wrote:
On Sunday, 13 July 2014 at 07:18:53 UTC, Walter Bright wrote:
On 7/10/2014 5:54 AM, Dicebot wrote:
No one but Walter / Andrei can do anything about it. Right now we are in weird
situation when they call for lieutenants but are not ready to abandon decision
On 7/13/2014 4:05 AM, Dicebot wrote:
Also I was not speaking originally about all good pull requests just waiting
to be merged but about stuff that hits some controversial language/Phobos parts
and requires some decision if it can be accepted at all. Pretty much no one but
you can make such
On Friday, 11 July 2014 at 21:04:05 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 10, 2014 at 08:10:36PM +, via Digitalmars-d
wrote:
Hmm. Seems that you're addressing a somewhat wider scope than
what I had
in mind. I was thinking mainly of 'scope' as does not escape
the body
of this
On Friday, 11 July 2014 at 22:03:37 UTC, H. S. Teoh via
Digitalmars-d wrote:
Along these lines, I'm wondering if turtles all the way down
is the
wrong way of looking at it. Consider, for example, an n-level
deep
nesting of aggregates. If obj.nest1 is const, then
obj.nest1.nest2.x
must also be
On 7/10/2014 10:53 PM, deadalnix wrote:
Most of them never gathered any attention.
Sometimes, when the idea is right, you still need to get behind and push it.
Build it and they will come is a stupid hollywood fantasy.
I've also written DIPs, which garnered zero comments. I implemented
Am Sat, 12 Jul 2014 13:27:26 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 7/10/2014 10:53 PM, deadalnix wrote:
Most of them never gathered any attention.
Sometimes, when the idea is right, you still need to get behind and
push it. Build it and they will come is a stupid
On 7/12/14, 1:38 PM, Johannes Pfau wrote:
But you've got some nice bonus:
If somebody doesn't like your pull request you can just merge it anyway.
That hasn't happened in a really long time, and last time it did is
before we had due process in place.
But if you veto something the only one
On 7/12/14, 1:27 PM, Walter Bright wrote:
On 7/10/2014 10:53 PM, deadalnix wrote:
Most of them never gathered any attention.
Sometimes, when the idea is right, you still need to get behind and push
it. Build it and they will come is a stupid hollywood fantasy.
I've also written DIPs, which
On 7/12/2014 1:38 PM, Johannes Pfau wrote:
But you've got some nice bonus:
If somebody doesn't like your pull request you can just merge it anyway.
I'd only do that in an emergency. I'll also just pull the ones for D1.
But if you veto something the only one who can probably merge anyway is
I'm bugging around with a similar proposal for a while, but quite
fail to put the last pieces in place. It goes similar in
On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via
Digitalmars-d wrote:
- For function parameters, this lifetime is the scope of the
function
body.
Some
On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
Instead of lifetime intersections with `` (I believe Timon
proposed that in the original thread), simply specify multiple
owners: `scope!(a, b)`. This works, because as far as I can
see there is no need for lifetime unions, only
On 10/07/14 20:15, H. S. Teoh via Digitalmars-d wrote:
class C {}
C myFunc(C obj) {
obj.doSomething();
return obj; // will be rejected if parameters are scoped by
default
}
Hmm, why wouldn't that work? The scope where you called myFunc
On 10/07/2014 19:03, Walter Bright wrote:
On 7/10/2014 9:00 AM, Nick Treleaven wrote:
On 09/07/2014 20:55, Walter Bright wrote:
Unique!(int*) u = new int; // must work
That works, it's spelled:
Unique!int u = new int;
I'm unconfortable with that design, as T can't be a class ref or a
On Thursday, 10 July 2014 at 22:50:51 UTC, Walter Bright wrote:
On 7/10/2014 1:52 PM, bearophile wrote:
Walter Bright:
I can't imagine users going to the bother of typing all that,
let alone what
happens when they do it wrong. Most users don't really have a
good handle on
what the lifetimes
On 10/07/14 22:31, Walter Bright wrote:
I don't know the PR link nor do I know what pseudonym you use on github,
so please help!
I reiterate my complaint that people use virtual functions for their
github handles. There's no reason to. Who knows that 9il is actually
Ilya Yaroshenko? Took me 3
On Tuesday, 8 July 2014 at 23:43:47 UTC, Meta wrote:
Is the code public already ?
https://github.com/andralex/std_allocator
Maybe Andrei should remove this outdated version to reduce
confusion, if nobody uses it that is :)
/Per
On Thursday, 10 July 2014 at 21:46:50 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 10 July 2014 at 21:40:15 UTC, Sean Kelly wrote:
:-) To compensate, I use the same virtual function literally
everywhere. Same icon photo too.
That's Go…
And Go is awesome. I could change it to my face, but
On Fri, Jul 11, 2014 at 08:56:10AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 10/07/14 20:15, H. S. Teoh via Digitalmars-d wrote:
class C {}
C myFunc(C obj) {
obj.doSomething();
return obj; // will be rejected if parameters are scoped by
On Thursday, 10 July 2014 at 20:31:53 UTC, Walter Bright wrote:
I reiterate my complaint that people use virtual functions
for their github handles. There's no reason to. Who knows that
9il is actually Ilya Yaroshenko? Took me 3 virtual function
dispatches to find that out!
So, final by
On Fri, Jul 11, 2014 at 01:14:37AM +, Meta via Digitalmars-d wrote:
On Friday, 11 July 2014 at 01:08:59 UTC, Andrei Alexandrescu wrote:
On 7/10/14, 2:25 PM, Walter Bright wrote:
On 7/10/2014 1:49 PM, Robert Schadek via Digitalmars-d wrote:
On 7/11/2014 4:44 AM, Nick Treleaven wrote:
On 10/07/2014 19:03, Walter Bright wrote:
On 7/10/2014 9:00 AM, Nick Treleaven wrote:
On 09/07/2014 20:55, Walter Bright wrote:
Unique!(int*) u = new int; // must work
That works, it's spelled:
Unique!int u = new int;
I'm unconfortable
On Thursday, 10 July 2014 at 22:53:18 UTC, Walter Bright wrote:
On 7/10/2014 1:57 PM, Marc Schütz schue...@gmx.net wrote:
That leaves relatively few cases
Right, and do those cases actually matter?
Besides what I mentioned there is also slicing and ranges (not
only of arrays). These are
On Friday, 11 July 2014 at 06:49:26 UTC, deadalnix wrote:
On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
Instead of lifetime intersections with `` (I believe Timon
proposed that in the original thread), simply specify multiple
owners: `scope!(a, b)`. This works, because as far
On Thu, Jul 10, 2014 at 08:10:36PM +, via Digitalmars-d wrote:
I've been working on a proposal for ownership and borrowing since some
time, and I seem to have come to a very similar result as you have. It
is not really ready, because I keep discovering weaknesses, and can
only work on it
On Fri, Jul 11, 2014 at 06:41:47AM +, deadalnix via Digitalmars-d wrote:
[...]
On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via Digitalmars-d
wrote:
- For function parameters, this lifetime is the scope of the
function body.
Some kind of inout scope seem less limiting.
On Thursday, 10 July 2014 at 21:29:30 UTC, Dmitry Olshansky wrote:
Not digging into the whole thread.
9. Extensible I/O package to replace our monolitic std.stdio
sitting awkwardly on top of C's legacy. That would imply
integrating it with sockets/pipes and filters/codecs
(compression,
On 07/10/2014 07:41 AM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jul 10, 2014 at 05:12:23AM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
- Lifetime parameters. (it's more future-proof if they are not
introduced by simple identifiers.)
Eg.: void foo[lifetime lt](int x){ ... }
-
On 7/9/14, 8:59 PM, logicchains wrote:
On Thursday, 10 July 2014 at 02:12:18 UTC, Atila Neves wrote:
Rob Pike has said multiple times that the key/unique thing about Go is
select and that goroutines are the easy part. I'm not entirely sure
I grok what he means but we should if we're going to
On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu
wrote:
We already have actor-style via std.concurrency. We also have
fork-join parallelism via std.parallel. What we need is a
library for CSP.
The actor-style via std.concurrency is only between 'heavyweight'
threads though, no?
On 7/9/2014 8:12 PM, Timon Gehr wrote:
3. have a design and a plan that gets there
There's no law that says D refs must be exactly like Rust borrowed. We
can come up with a design that works best for D. D != Rust. Do you have
a design in mind?
...
Roughly, but not with 'ref'. It is also an
On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
8. NotNull!T type
For those that want a non-nullable reference type. This
should be doable
as a library type.
No.
Rationale?
Please, we've gone through this again and again and again and
again.
On Wednesday, 9 July 2014 at 20:51:04 UTC, Walter Bright wrote:
On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
Hmmm... how about using u after that?
Using u after that would either cause an exception to be
thrown, or they'd get T.init as a value. I tend to favor the
latter, but of course
On Thursday, 10 July 2014 at 06:32:32 UTC, logicchains wrote:
On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu
wrote:
We already have actor-style via std.concurrency. We also have
fork-join parallelism via std.parallel. What we need is a
library for CSP.
The actor-style via
On 7/9/2014 11:59 PM, deadalnix wrote:
On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
8. NotNull!T type
For those that want a non-nullable reference type. This should be doable
as a library type.
No.
Rationale?
Please, we've gone through this again and again and again and
On 7/10/2014 12:03 AM, deadalnix wrote:
So runtime error or php style better anything than nothing for something that
can be checked statically...
I don't understand your comment.
Walter Bright:
Exactly. I'm not seeing how this can work that well.
Do you have an example where this works badly? You can require
the @notnull annotations on the arguments at module/package
boundaries.
But I think this thread tries to face too many problems in
parallel. Even just the
On 7/10/2014 12:23 AM, Walter Bright wrote:
On 7/9/2014 11:59 PM, deadalnix wrote:
On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
8. NotNull!T type
For those that want a non-nullable reference type. This should be doable
as a library type.
No.
Rationale?
Please, we've
On 09/07/14 15:45, Meta wrote:
As far as I know, there's no reason we can't add pattern matching to
switch or final switch or both. There's no ambiguity because right now
it's not possible to switch on structs or classes. See Kenji's DIP32 for
syntax for tuples that could be leveraged.
On 10/07/14 05:59, logicchains wrote:
It's been implemented in Rust[1] via a macro, and can be implemented in
Haskell[2] without compiler support, so I'd be surprised if it wasn't
already possible to implement in D. It wouldn't however be as useful as
Go's until D gets message passing between
On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote:
Yes, I mean transitive, and understand what that implies.
I am positively shocked :)
I have started work on porting the CDGC to D2, have compilable
version (that was
easy thanks to earlier Sean work) but updating implementation
On Thursday, 10 July 2014 at 03:59:15 UTC, logicchains wrote:
Actually, an important question that should be considered: does
D want actor-style concurrency, like Erlang and Akka, or
CSP-style concurrency, like Rust, Go and Haskell? Or both?
Deciding this would allow efforts to be more
On Thursday, 10 July 2014 at 10:43:39 UTC, Dicebot wrote:
On Thursday, 10 July 2014 at 03:59:15 UTC, logicchains wrote:
Actually, an important question that should be considered:
does D want actor-style concurrency, like Erlang and Akka, or
CSP-style concurrency, like Rust, Go and Haskell? Or
On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
Are there any tutorials or blog posts out there demonstrating
how to use this? I think posts along the lines of This is a
CSP/message passing program in Go/Erlang. This is the same
program translated into D; look how concise and
On 10/07/14 01:57, H. S. Teoh via Digitalmars-d wrote:
[...]
I'm sure there are plenty of holes in this proposal, so destroy away.
;-)
You should post this in a new thread.
I'm wondering if a lot more data can be statically allocated. Then
passed by reference to functions taking scope
Dicebot:
I can't blame Sonke or anyone else for not wanting to waste his
time on pushing more stuff upstream considering how miserable
contribution experience is right now.
This was one of the causes of the creation of Tango and its
fiasco, so better to not repeat that.
Bye,
bearophile
On Thursday, 10 July 2014 at 11:19:26 UTC, Dicebot wrote:
On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
Are there any tutorials or blog posts out there demonstrating
how to use this? I think posts along the lines of This is a
CSP/message passing program in Go/Erlang. This is
On Thursday, 10 July 2014 at 12:13:03 UTC, bearophile wrote:
Dicebot:
I can't blame Sonke or anyone else for not wanting to waste
his time on pushing more stuff upstream considering how
miserable contribution experience is right now.
This was one of the causes of the creation of Tango and
Dicebot:
No one but Walter / Andrei can do anything about it. Right now
we are in weird situation when they call for lieutenants but
are not ready to abandon decision power. It can't possibly work
that way. No amount of volunteer effort will help when so many
PR stall waiting for resolution
On Wednesday, 9 July 2014 at 23:58:39 UTC, H. S. Teoh via
Digitalmars-d wrote:
So here's a first stab at refining (and extending) what 'scope'
should be:
In general, I like it, but can scopedness be inferred? The
impression I get from this is we're supposed to manually annotate
every
On 7/9/14, 11:59 PM, deadalnix wrote:
On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
8. NotNull!T type
For those that want a non-nullable reference type. This should be
doable
as a library type.
No.
Rationale?
Please, we've gone through this again and again and again and
On 7/10/14, 12:54 AM, Walter Bright wrote:
On 7/10/2014 12:23 AM, Walter Bright wrote:
On 7/9/2014 11:59 PM, deadalnix wrote:
On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
8. NotNull!T type
For those that want a non-nullable reference type. This should be
doable
as a
On 7/10/14, 12:21 AM, Walter Bright wrote:
On 7/10/2014 12:03 AM, deadalnix wrote:
So runtime error or php style better anything than nothing for
something that
can be checked statically...
I don't understand your comment.
It's very simple. The semantics you propose is move with the syntax
On Thursday, 10 July 2014 at 13:09:42 UTC, bearophile wrote:
Dicebot:
No one but Walter / Andrei can do anything about it. Right now
we are in weird situation when they call for lieutenants but
are not ready to abandon decision power. It can't possibly
work that way. No amount of volunteer
On Thursday, 10 July 2014 at 12:54:19 UTC, Dicebot wrote:
On Thursday, 10 July 2014 at 12:13:03 UTC, bearophile wrote:
Dicebot:
I can't blame Sonke or anyone else for not wanting to waste
his time on pushing more stuff upstream considering how
miserable contribution experience is right now.
On Thursday, 10 July 2014 at 14:09:41 UTC, John Colvin wrote:
To be fair to Walter/Andrei, you need to be clear who your
lieutenant is before you can delegate to them.
Who has stepped up to take charge of concurrency in D?
I think it should be other way around - announcing slot with
listed
On Thursday, 10 July 2014 at 14:14:20 UTC, Dicebot wrote:
On Thursday, 10 July 2014 at 14:09:41 UTC, John Colvin wrote:
To be fair to Walter/Andrei, you need to be clear who your
lieutenant is before you can delegate to them.
Who has stepped up to take charge of concurrency in D?
I think it
On 7/10/14, 5:54 AM, Dicebot wrote:
On Thursday, 10 July 2014 at 12:13:03 UTC, bearophile wrote:
Dicebot:
I can't blame Sonke or anyone else for not wanting to waste his time
on pushing more stuff upstream considering how miserable contribution
experience is right now.
This was one of the
On 7/10/14, 7:24 AM, John Colvin wrote:
On Thursday, 10 July 2014 at 14:14:20 UTC, Dicebot wrote:
On Thursday, 10 July 2014 at 14:09:41 UTC, John Colvin wrote:
To be fair to Walter/Andrei, you need to be clear who your lieutenant
is before you can delegate to them.
Who has stepped up to take
On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu
wrote:
Then there's stuff I have no expertise in such as
https://github.com/D-Programming-Language/phobos/pull/2307. Not
only I'm not on hook for that, I better not discuss and pull
that and leave it to someone who knows curl
On Wednesday, 9 July 2014 at 21:47:47 UTC, Andrei Alexandrescu
wrote:
On 7/9/14, 1:51 PM, Walter Bright wrote:
On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
Hmmm... how about using u after that?
Using u after that would either cause an exception to be
thrown, or
they'd get T.init as a
E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some
apparently work that's just sitting there abandoned.
Hm, slightly OT: is it considered widely acceptable to take over
such pull requests by reopening rebased one with identical
content? I presume Boost licensing implies
On Thursday, 10 July 2014 at 06:32:32 UTC, logicchains wrote:
On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu
wrote:
We already have actor-style via std.concurrency. We also have
fork-join parallelism via std.parallel. What we need is a
library for CSP.
The actor-style via
On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
Reading the code in the pull request [1], for instance, makes
me wonder how to tell if `spawn()` is spawning a thread or a
fibre. Can a tid refer to a fibre? If so, why's it called a
thread ID, and how do I tell if a particular
On Thursday, 10 July 2014 at 11:19:26 UTC, Dicebot wrote:
Problem is that this is most simple PR to simply add
message-passing support for fibers. Adding some advanced
schedulers with worker thread pool can be expected to be done
on top but.. This small PR has been rotting there for ages
On Thursday, 10 July 2014 at 14:54:51 UTC, Dicebot wrote:
E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is
some
apparently work that's just sitting there abandoned.
Hm, slightly OT: is it considered widely acceptable to take
over such pull requests by reopening rebased one
On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu
wrote:
Switching to newer pull requests, there are simple and
obviously good pull requests that just sit there for anyone to
pull.
This. I think pull requests tend to sit because people don't
feel they have the authority to
On 7/10/14, 8:29 AM, Sean Kelly wrote:
Robert's struggle with getting std.logger accepted is the stuff told to
children around the campfire so they don't venture out into the dark.
Actually we use his logger at Facebook quite extensively (and happily).
-- Andrei
On Thursday, 10 July 2014 at 15:35:03 UTC, John Colvin wrote:
On Thursday, 10 July 2014 at 14:54:51 UTC, Dicebot wrote:
E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is
some
apparently work that's just sitting there abandoned.
Hm, slightly OT: is it considered widely
On 7/10/14, 7:53 AM, Sean Kelly wrote:
On Wednesday, 9 July 2014 at 21:47:47 UTC, Andrei Alexandrescu wrote:
On 7/9/14, 1:51 PM, Walter Bright wrote:
On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
Hmmm... how about using u after that?
Using u after that would either cause an exception to
On 7/10/14, 7:54 AM, Dicebot wrote:
E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some
apparently work that's just sitting there abandoned.
Hm, slightly OT: is it considered widely acceptable to take over such
pull requests by reopening rebased one with identical content?
1 - 100 of 302 matches
Mail list logo
