I'm sure this question has been asked a thousand times. I've even
asked similar questions in the past (I've been away for quite a
while). But all of the tutorials that I have found assume quite a
lot and leave a lot to be inferred. Is there a simple step by
step tutorial demonstrating how to ca
On 4/27/15 9:54 AM, Steven Schveighoffer wrote:
So I think the issue here is that the pkg installer on OSX does not
clean up the target directory if it already exists (or at least
purposely remove thread.di). Will look into fixing that. At least now,
it works properly, thanks (did a rm -rf /usr/
On Monday, 11 May 2015 at 22:46:00 UTC, Per Nordlöw wrote:
The pattern
final switch (_index)
{
import std.range: empty, front;
foreach (i, R; Rs)
{
case i:
assert(!source[i].empty)
The pattern
final switch (_index)
{
import std.range: empty, front;
foreach (i, R; Rs)
{
case i:
assert(!source[i].empty);
return source[i].front;
On Saturday, 9 May 2015 at 23:32:49 UTC, Adam D. Ruppe wrote:
On Saturday, 9 May 2015 at 13:00:01 UTC, wobbles wrote:
On Linux, I'm able to edit a file descriptor after I've
created it to tell it to read/write asynchronously, I cant
seem to find anything similar on windows however.
Asynchrono
> std.process.ProcessException@std\process.d(560):
> Failed to spawn new process
This is the error-message from the D-script from
http://wiki.dlang.org/Building_DMD
-manfred
On Monday, 11 May 2015 at 15:38:55 UTC, Ali Çehreli wrote:
On 05/11/2015 03:48 AM, tcak wrote:
> I think `destroy`'s behaviour should be documented much
better.
Could others tell us the missing pieces please.
Perhaps related to this discussion, the following document says
"does not initiate a
On Monday, 11 May 2015 at 13:44:14 UTC, Adam D. Ruppe wrote:
On Monday, 11 May 2015 at 13:37:27 UTC, ref2401 wrote:
Why does it happen?
You'd just be writing to the immutable memory through a
different name.
Consider if someone took a reference to one of those immutable
ints, expecting it
On Monday, 11 May 2015 at 13:37:27 UTC, ref2401 wrote:
Why does it happen?
You'd just be writing to the immutable memory through a different
name.
Consider if someone took a reference to one of those immutable
ints, expecting it to never change. Then you wrote a new struct
over the same lo
struct MyStruct {
this(int a, int b) {
this.a = a;
this.b = b;
}
immutable int a;
immutable int b;
}
void main(string[] args) {
MyStruct[] arr = new MyStruct[3];
arr[0] = MyStruct(5, 7);
}
Why does it happen
On Monday, 11 May 2015 at 10:48:22 UTC, tcak wrote:
On Monday, 11 May 2015 at 10:30:11 UTC, Daniel Kozak wrote:
On Monday, 11 May 2015 at 10:24:57 UTC, Daniel Kozák wrote:
On Mon, 11 May 2015 09:40:28 +
tcak via Digitalmars-d-learn
wrote:
But yes I would say, it is not intentional beh
On Monday, 11 May 2015 at 10:30:11 UTC, Daniel Kozak wrote:
On Monday, 11 May 2015 at 10:24:57 UTC, Daniel Kozák wrote:
On Mon, 11 May 2015 09:40:28 +
tcak via Digitalmars-d-learn
wrote:
But yes I would say, it is not intentional behaviour. It
should use
weak reference, so It would be
On Monday, 11 May 2015 at 10:24:57 UTC, Daniel Kozák wrote:
On Mon, 11 May 2015 09:40:28 +
tcak via Digitalmars-d-learn
wrote:
On Monday, 11 May 2015 at 09:20:50 UTC, Daniel Kozák wrote:
>
> On Mon, 11 May 2015 09:09:07 +
> tcak via Digitalmars-d-learn
> wrote:
>
>
> I think sync
On Mon, 11 May 2015 09:40:28 +
tcak via Digitalmars-d-learn wrote:
> On Monday, 11 May 2015 at 09:20:50 UTC, Daniel Kozák wrote:
> >
> > On Mon, 11 May 2015 09:09:07 +
> > tcak via Digitalmars-d-learn
> > wrote:
> >
> >
> > I think synchronize(this) prevents GC from collect memory
>
>
On Mon, 11 May 2015 09:40:28 +
tcak via Digitalmars-d-learn wrote:
> On Monday, 11 May 2015 at 09:20:50 UTC, Daniel Kozák wrote:
> >
> > On Mon, 11 May 2015 09:09:07 +
> > tcak via Digitalmars-d-learn
> > wrote:
> >
> >
> > I think synchronize(this) prevents GC from collect memory
>
>
On Monday, 11 May 2015 at 07:12:05 UTC, Per Nordlöw wrote:
I guess we should support bi-directional access through back()
and popBack() aswell right?
I believe I have BidirectionalRange support aswell now at
https://github.com/nordlow/justd/blob/master/range_ex.d#L597
On Monday, 11 May 2015 at 09:20:50 UTC, Daniel Kozák wrote:
On Mon, 11 May 2015 09:09:07 +
tcak via Digitalmars-d-learn
wrote:
I think synchronize(this) prevents GC from collect memory
I am not sure whether this is expected behaviour from
`synchronization` keyword.
Similar code in
On Mon, 11 May 2015 09:09:07 +
tcak via Digitalmars-d-learn wrote:
> [code]
> import std.stdio;
>
> class Connection{
> private void other() shared{}
>
> public void close() shared{
> synchronized( this ){
> other();
> }
>
On Monday, 11 May 2015 at 09:09:09 UTC, tcak wrote:
[code]
import std.stdio;
class Connection{
private void other() shared{}
public void close() shared{
synchronized( this ){
other();
}
}
public void hasDat
[code]
import std.stdio;
class Connection{
private void other() shared{}
public void close() shared{
synchronized( this ){
other();
}
}
public void hasData() shared{ writeln("Has Data"); }
}
void main() {
On Monday, 11 May 2015 at 07:05:30 UTC, Per Nordlöw wrote:
So I implemented a first working version of merge() by reusing
roundRobin(). Working version at:
https://github.com/nordlow/justd/blob/master/range_ex.d#L599
Destroy!
I guess we should support bi-directional access through back()
an
On Monday, 11 May 2015 at 07:12:05 UTC, Per Nordlöw wrote:
I guess we should support bi-directional access through back()
and popBack() aswell right?
Does this mean that we need to statically check whether the
SortedRanges support Bidirectional access or not? Or is a
SortedRange by convention
On Thursday, 7 May 2015 at 21:53:24 UTC, Per Nordlöw wrote:
Thanks. These are good ideas in general. I'm curious to why
something like merge isn't already in Phobos. The most similar
existing range in Phobos is probably
So I implemented a first working version of merge() by reusing
roundRobin(
23 matches
Mail list logo
