On Wednesday, 5 August 2015 at 02:26:48 UTC, Meta wrote:
On Wednesday, 5 August 2015 at 01:27:53 UTC, Steven
Schveighoffer wrote:
On 8/4/15 9:02 PM, DarthCthulhu wrote:
writefln("PQ: %s", pq.queue); <- prints PQ: [Tuple!(int,
string)(3,
"HELLO3"), Tuple!(int, string)(10, "HELLO10"), Tuple
On Wednesday, 5 August 2015 at 01:27:53 UTC, Steven Schveighoffer
wrote:
On 8/4/15 9:02 PM, DarthCthulhu wrote:
writefln("PQ: %s", pq.queue); <- prints PQ: [Tuple!(int,
string)(3,
"HELLO3"), Tuple!(int, string)(10, "HELLO10"), Tuple!(int,
string)(11,
"HELLO11")]
This is probably consum
On Wednesday, 5 August 2015 at 01:27:53 UTC, Steven Schveighoffer
wrote:
On 8/4/15 9:02 PM, DarthCthulhu wrote:
writefln("PQ: %s", pq.queue); <- prints PQ: [Tuple!(int,
string)(3,
"HELLO3"), Tuple!(int, string)(10, "HELLO10"), Tuple!(int,
string)(11,
"HELLO11")]
This is probably consum
On 8/4/15 9:02 PM, DarthCthulhu wrote:
writefln("PQ: %s", pq.queue); <- prints PQ: [Tuple!(int, string)(3,
"HELLO3"), Tuple!(int, string)(10, "HELLO10"), Tuple!(int, string)(11,
"HELLO11")]
This is probably consuming your queue, popping all the data off as it
prints. If you print the len
So I've just gotten into D and decided to have a go at creating
something relatively simple to get my feet wet: a priority queue.
Seemed like a simple enough thing, right? It's a pretty basic
data structure, it can't possibly be THAT difficult, right?
First, I tried using associative arrays on
On Monday, 3 August 2015 at 22:42:15 UTC, SirNickolas wrote:
Hello! I'm new in D and it is amazing!
Can you tell me please if it is discouraged or deprecated to
call a function by just putting its name, without brackets?
It's quite unusual for me (used C++ and Python before), but I
can see th
On 08/04/2015 09:19 AM, Dicebot wrote:
receiveTimeout
I think the problem here is that the worker is busy, not even able to
call that.
This sounds like sending a signal to the specific thread (with
pthread_kill()) but I don't know the details of it nor whether Phobos
supports it.
Ali
receiveTimeout
Is there a good way to stop work-intensive threads via thread
communication (instead of using a shared variable)? The example
below is very basic and naive and only meant to exemplify the
basic problem.
I want to stop (and abort) the worker as soon as new input
arrives. However, while executi
fix - https://github.com/D-Programming-Language/phobos/pull/3524
On Tuesday, 4 August 2015 at 11:42:54 UTC, Dicebot wrote:
On Tuesday, 4 August 2015 at 11:33:11 UTC, 岩倉 澪 wrote:
On Tuesday, 4 August 2015 at 10:37:39 UTC, Dicebot wrote:
std.concurrency does by-value message passing (in this case
just ptr+length), it never deep copies automatically
I assumed
On Tuesday, 4 August 2015 at 11:33:11 UTC, 岩倉 澪 wrote:
On Tuesday, 4 August 2015 at 10:37:39 UTC, Dicebot wrote:
std.concurrency does by-value message passing (in this case
just ptr+length), it never deep copies automatically
I assumed that it would deep copy (in the case of mutable data)
sin
On Tuesday, 4 August 2015 at 08:18:58 UTC, John Colvin wrote:
On Tuesday, 4 August 2015 at 03:20:38 UTC, Craig Dillabaugh
wrote:
I can now run it with:
LD_LIBRARY_PATH=/home/craig2/code/gdal-2.0.0/lib64 ./gdaltest
But it appears the LD_LIBRARY_PATH hack is causing havoc with
other libraries,
On Tuesday, 4 August 2015 at 04:21:27 UTC, Joakim Brännström
wrote:
On Tuesday, 4 August 2015 at 03:20:38 UTC, Craig Dillabaugh
wrote:
clip
Linkers, so fun they are...
https://wiki.debian.org/RpathIssue
As you can see in the search order RPATH takes precedence over
LD_LIBRARY_PATH.
If we ass
On Tuesday, 4 August 2015 at 10:37:39 UTC, Dicebot wrote:
std.concurrency does by-value message passing (in this case
just ptr+length), it never deep copies automatically
I assumed that it would deep copy (in the case of mutable data)
since the data being sent is thread-local (unless I am
mis
On Monday, 3 August 2015 at 21:32:05 UTC, DLearner wrote:
Looks like 0-base is fixed, to avoid problems with existing
code.
But nothing stops _adding_ to the language by allowing
int[x:y] foo to mean valid symbols are foo[x], foo[x+1],...,
foo[y].
Plus rule that int[:y] means valid symbols are
On Tuesday, 4 August 2015 at 10:29:57 UTC, 岩倉 澪 wrote:
On Tuesday, 4 August 2015 at 08:35:10 UTC, Dicebot wrote:
auto output = receiveOnly!(immutable(Bar)[]);
Won't message passing like this result in an expensive copy, or
does the cast to immutable via assumeUnique avoid that?
immutabl
On Tue, 04 Aug 2015 10:29:55 +
"岩倉 澪" wrote:
> On Tuesday, 4 August 2015 at 08:35:10 UTC, Dicebot wrote:
> > auto output = receiveOnly!(immutable(Bar)[]);
>
> Won't message passing like this result in an expensive copy
No it will copy only struct containing length and pointer to data,
On Tuesday, 4 August 2015 at 08:36:26 UTC, John Colvin wrote:
Do you mean this instead?
spawn(&fooPtrToBarArr, foo, bar);
Yep, that was a typo when writing up the post!
Anyway, you need to use shared, not __gshared, then it should
work.
I have been wary of shared because of:
https://p0nce
On Tuesday, 4 August 2015 at 08:35:10 UTC, Dicebot wrote:
auto output = receiveOnly!(immutable(Bar)[]);
Won't message passing like this result in an expensive copy, or
does the cast to immutable via assumeUnique avoid that?
import std.concurrency;
import std.typecons : Unique;
import std.exception : assumeUnique;
struct Foo { }
struct Bar { }
void bar_generator (Tid ownerTid)
{
receive(
(shared(Foo)* input) {
auto output = new Bar[100];
// compute output ..
// .. and
On Tuesday, 4 August 2015 at 08:03:54 UTC, 岩倉 澪 wrote:
Hi all, I'm a bit confused today (as usual, haha).
I have a pointer to a struct (let's call it Foo) allocated via
a C library.
I need to do some expensive computation with the Foo* to create
a Bar[], but I would like to do that computation
On 08/04/2015 01:03 AM, "岩倉 澪" wrote:
Hi all, I'm a bit confused today (as usual, haha).
I have a pointer to a struct (let's call it Foo) allocated via a C library.
I need to do some expensive computation with the Foo* to create a Bar[],
but I would like to do that computation in the background,
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote:
Does the D language set in stone that the first element of an
array _has_ to be index zero?
Wouldn't starting array elements at one avoid the common
'off-by-one' logic error, it does
seem more natural to begin a count at 1.
I, too, d
On Tuesday, 4 August 2015 at 03:20:38 UTC, Craig Dillabaugh wrote:
I can now run it with:
LD_LIBRARY_PATH=/home/craig2/code/gdal-2.0.0/lib64 ./gdaltest
But it appears the LD_LIBRARY_PATH hack is causing havoc with
other libraries, as I get errors loading other shared libraries
when I do that.
Hi all, I'm a bit confused today (as usual, haha).
I have a pointer to a struct (let's call it Foo) allocated via a
C library.
I need to do some expensive computation with the Foo* to create a
Bar[], but I would like to do that computation in the background,
because the Bar[] is not needed rig
26 matches
Mail list logo