Re: [std.net.curl] Downloading multiple files using download()
On Sunday, 28 December 2014 at 07:52:24 UTC, ketmar via Digitalmars-d-learn wrote: On Sun, 28 Dec 2014 07:44:33 + Jack via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: How does one compile for Windows on a Linux Machine using dub? I've been using the platform : [windows] configuration in my dub.json to no avail since my Windows installation keeps on screaming out compatibility problems. i don't think that you can do cross-developement with dub now. i believe that the best thing you can do is to run dub.exe and dmd.exe with wine. yet the last time i checked (that was a while ago) dmd.exe with wine was able to produce only segfaults. yet i'm not an expert in both dub and windows, so i don't really know. i think that cross-developmenet question worth a separate topic. Well that's a shame then. Thanks for the help ketmar.
Re: Need example of usage DerelictPQ
Adam, I trying to build simple app:
import std.stdio;
import postgres;
import database;
void main() {
auto db = new PostgreSql(dbname = test2);
foreach(line; db.query(SELECT * FROM customer)) {
writeln(line[0], line[customer_id]);
}
}
and getting next error:
D:\123dmd app.d database.d postgres.d
postgres.d(124): Error: struct database.Row member resultSet is
not accessible
postgres.d(139): Error: struct database.Row member row is not
accessible
Also I can't understand why I do not need specify login and pass
when I connection to DB?
`shared Mutex`?
Hello all, This is my first post on these forums. I've been learning D for the past couple of months or so and have been quite impressed by the language thus far. One stumbling block that I have encountered is with using `shared`, and more specifically using `shared` with synchronization tools like Mutex and Condition. Consider the following program: https://gist.github.com/anibali/4d544c31ac762409d4ea I can't seem to get the thing working without a bunch of casts to and from `shared`, which I'm assuming is not a good practice - it definitely doesn't make for nice-looking code. I've found an old thread on a similar issue(http://forum.dlang.org/thread/moyyibrpnnmrrovyl...@forum.dlang.org) but there doesn't seem to be a conclusion there either. Is `shared` in a workable state? Shouldn't Mutex, Condition, etc be shared since they are basically only ever useful when used in multiple threads? Am I missing the point completely?
Re: `shared Mutex`?
On 12/28/14 10:24, Aiden via Digitalmars-d-learn wrote: Is `shared` in a workable state? No. Shouldn't Mutex, Condition, etc be shared since they are basically only ever useful when used in multiple threads? Yes, but there are so many problems with 'shared' that using it that way (even only as a type constructor) is impractical. artur
Re: `shared Mutex`?
On Sunday, 28 December 2014 at 09:24:31 UTC, Aiden wrote: Hello all, This is my first post on these forums. I've been learning D for the past couple of months or so and have been quite impressed by the language thus far. One stumbling block that I have encountered is with using `shared`, and more specifically using `shared` with synchronization tools like Mutex and Condition. Consider the following program: https://gist.github.com/anibali/4d544c31ac762409d4ea I can't seem to get the thing working without a bunch of casts to and from `shared`, which I'm assuming is not a good practice - it definitely doesn't make for nice-looking code. I've found an old thread on a similar issue(http://forum.dlang.org/thread/moyyibrpnnmrrovyl...@forum.dlang.org) but there doesn't seem to be a conclusion there either. Is `shared` in a workable state? Shouldn't Mutex, Condition, etc be shared since they are basically only ever useful when used in multiple threads? Am I missing the point completely? Unfortunately, the current way to use shared is pretty much what you are doing now. It's probably one of the least understood and difficult to work with parts of the language.
Order of evaluation of post-increment operator
I was just taking a look at the following poll[1] about the order
of evaluation when using the post-increment operator. The
following D snippet shows an example.
import std.stdio;
void main(string[] args)
{
auto foo = [0, 0];
int i = 0;
foo[i++] = i++; // Woah!
writefln(%s, foo);
}
Apparently the C++ equivalent is undefined behaviour but when run
using D the following result is output:
[1, 0]
1. Can someone please explain this output?
2. Is there anywhere this order of evaluation is documented?
3. Do you agree this is right?
[1]:
http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation/
Re: Order of evaluation of post-increment operator
On Sunday, 28 December 2014 at 14:51:22 UTC, Gary Willoughby
wrote:
I was just taking a look at the following poll[1] about the
order of evaluation when using the post-increment operator. The
following D snippet shows an example.
import std.stdio;
void main(string[] args)
{
auto foo = [0, 0];
int i = 0;
foo[i++] = i++; // Woah!
writefln(%s, foo);
}
Apparently the C++ equivalent is undefined behaviour but when
run using D the following result is output:
[1, 0]
1. Can someone please explain this output?
2. Is there anywhere this order of evaluation is documented?
3. Do you agree this is right?
[1]:
http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation/
It has been pointed before that this behavior even varies by D
compiler:
http://forum.dlang.org/post/swczuwclttmoakpve...@forum.dlang.org
One of those many small details that will have to be tightened up
in the spec someday.
[std.net.curl] [Windows-only] Peer authentication problem
I've encountered this problem back when I was still programming on Windows and I have encountered this again as I guide my friend into compiling a Windows-usable version of my software: http://picpaste.com/pics/10884707_1128873367127279_796341276_n-AEeMhXiv.1419779219.jpg The program has no hiccup about peer authentication on Linux but the problem still remains on Windows. We've tried: conn.verifyPeer = false; conn.verifyHost = false; conn.handle.set(CurlOption.ssl_verifypeer, 0); To no avail. Is this a bug or am I just missing something?
Re: Importing a module from another directory
On Saturday, 27 December 2014 at 17:36:39 UTC, Derix wrote: I try to compile the basic HelloWorld.d example in which I only added import Journal; where Journal is a module I defined in Journal.d in another directory. So I have /home/derix/development/publishing/journal/journal.d and /home/derix/development/examples/helloworld/main.d I work with MonoDevelop. In Project/Project Options/Includes I specified /home/derix/development/publishing/journal Building from MonoDevelop spews the following command line dmd -debug -gc main.d -I/usr/include/dmd -I/home/derix/development/publishing/journal -odobj/Debug -of/home/derix/development/example/helloworld/bin/Debug/example -w and the following error --- errorlevel 1 obj/Debug/example.o:(.data+0x78): undefined reference to `_D7Journal12__ModuleInfoZ' What am I missing ? Or, to put it more simply, what would be the correct dmd command line to import a module defined in a sibling directory ? Thanks, If you use the dco,maybe it's ok: at /home/derix/development dco https://github.com/FrankLIKE/dco/ Frank
Re: Order of evaluation of post-increment operator
Gary Willoughby: 2. Is there anywhere this order of evaluation is documented? Currently that code is undefined in D too, and the compiler doesn't even give a compilation error. But Walter has said many times that it will become defined in D (IMHO it must be). Bye, bearophile
Re: Order of evaluation of post-increment operator
On Sunday, 28 December 2014 at 16:05:32 UTC, bearophile wrote: (IMHO it must be). Disallowing is an alternative to consider. Even defined behaviour can be unintuitive and error prone.
opDollar and length
A question that suddenly occurred to me, and I realized I didn't know the answer. Why is it necessary/desirable to define separate .length and .opDollar methods for custom types?
Re: opDollar and length
On Sunday, 28 December 2014 at 18:12:42 UTC, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: A question that suddenly occurred to me, and I realized I didn't know the answer. Why is it necessary/desirable to define separate .length and .opDollar methods for custom types? To allow slicing for types that don't have a length property but are terminated by a sentinel value, like null terminated strings or single linked lists. It's usefull for multi-dimensional containers as well.
Re: opDollar and length
On Sunday, December 28, 2014 18:21:41 Tobias Pankrath via Digitalmars-d-learn wrote: On Sunday, 28 December 2014 at 18:12:42 UTC, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: A question that suddenly occurred to me, and I realized I didn't know the answer. Why is it necessary/desirable to define separate .length and .opDollar methods for custom types? To allow slicing for types that don't have a length property but are terminated by a sentinel value, like null terminated strings or single linked lists. It's usefull for multi-dimensional containers as well. Indeed, though there's definitely been discussion of making it so that opDollar is not necessary under at least some circumstances when length is defined: https://issues.dlang.org/show_bug.cgi?id=7177 But unfortunately, the nitty gritty details are just complicated enough that it hasn't happened yet. I really wish that it would though so that we can require that random access ranges define opDollar and then actually be able to use opDollar for random access ranges in generic code. - Jonathan M Davis
Re: Order of evaluation of post-increment operator
On Sunday, 28 December 2014 at 17:34:52 UTC, Marc Schütz wrote:
On Sunday, 28 December 2014 at 16:05:32 UTC, bearophile wrote:
(IMHO it must be).
Disallowing is an alternative to consider. Even defined
behaviour can be unintuitive and error prone.
I guess there are cases where it's not easily catchable:
void foo(int* p0, int* p1)
{
(*p0)++ = (*p1)++;
}
what happens when p0 == p1?
Re: Order of evaluation of post-increment operator
Marc Schütz: On Sunday, 28 December 2014 at 16:05:32 UTC, bearophile wrote: (IMHO it must be). Disallowing is an alternative to consider. Even defined behaviour can be unintuitive and error prone. Right. Bye, bearophile
Re: `shared Mutex`?
Thanks for the information. At least I've discovered a reasonably
tidy way of wrapping Mutex up so that it's not quite as painful
casting everything:
shared class SharedMutex {
private Mutex mutex;
private @property Mutex unsharedMutex() {
return cast(Mutex)mutex;
}
this() {
mutex = cast(shared)new Mutex();
}
alias unsharedMutex this;
}
SharedMutex can just be used like a normal Mutex, which is pretty
neat. `alias this` is awesome!
Re: Order of evaluation of post-increment operator
John Colvin:
I guess there are cases where it's not easily catchable:
void foo(int* p0, int* p1)
{
(*p0)++ = (*p1)++;
}
what happens when p0 == p1?
The undefined code can be found statically, the run-time values
are irrelevant.
Bye,
bearophile
Re: `shared Mutex`?
On Sun, 28 Dec 2014 20:21:45 +
Aiden via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Thanks for the information. At least I've discovered a reasonably
tidy way of wrapping Mutex up so that it's not quite as painful
casting everything:
shared class SharedMutex {
private Mutex mutex;
private @property Mutex unsharedMutex() {
return cast(Mutex)mutex;
}
this() {
mutex = cast(shared)new Mutex();
}
alias unsharedMutex this;
}
SharedMutex can just be used like a normal Mutex, which is pretty
neat. `alias this` is awesome!
you can turn that method to template. for now it is virtual method and
compiler is unable to inline it.
signature.asc
Description: PGP signature
Re: Order of evaluation of post-increment operator
On Sun, 28 Dec 2014 17:34:50 + via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Sunday, 28 December 2014 at 16:05:32 UTC, bearophile wrote: (IMHO it must be). Disallowing is an alternative to consider. Even defined behaviour can be unintuitive and error prone. yep, 13670 times yep. ;-) signature.asc Description: PGP signature
Re: opDollar and length
On Sun, 28 Dec 2014 19:02:59 +0100 Joseph Rushton Wakeling via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: A question that suddenly occurred to me, and I realized I didn't know the answer. Why is it necessary/desirable to define separate .length and .opDollar methods for custom types? 'because you can't write this: auto len = myvar.$; and it's very tedious to write this: auto slc = myvar[myvar.length-5..myvar.length-3]; sure, compiler can use `opDollar` when you requested `length` and there is no such member. but it adds another quirk into language and may backstab you eventually. there is nothing hard in adding `alias length = opDollar;` (or vice versa) to type definition. signature.asc Description: PGP signature
Re: Order of evaluation of post-increment operator
On Sunday, 28 December 2014 at 14:51:22 UTC, Gary Willoughby
wrote:
I was just taking a look at the following poll[1] about the
order of evaluation when using the post-increment operator. The
following D snippet shows an example.
import std.stdio;
void main(string[] args)
{
auto foo = [0, 0];
int i = 0;
foo[i++] = i++; // Woah!
writefln(%s, foo);
}
Apparently the C++ equivalent is undefined behaviour but when
run using D the following result is output:
[1, 0]
1. Can someone please explain this output?
2. Is there anywhere this order of evaluation is documented?
3. Do you agree this is right?
[1]:
http://herbsutter.com/2014/12/01/a-quick-poll-about-order-of-evaluation/
Related thread:
http://forum.dlang.org/thread/amngdygrlsogzmefz...@forum.dlang.org#post-l92grb:242q5v:241:40digitalmars.com
Re: Order of evaluation of post-increment operator
On Sunday, 28 December 2014 at 20:25:59 UTC, bearophile wrote:
John Colvin:
I guess there are cases where it's not easily catchable:
void foo(int* p0, int* p1)
{
(*p0)++ = (*p1)++;
}
what happens when p0 == p1?
The undefined code can be found statically, the run-time values
are irrelevant.
Bye,
bearophile
It depends what you mean by undefined. Sure, the order of those
2 ++ operations is undefined in all cases, but it doesn't lead to
undefined *behaviour* unless the pointers are the same.
There's loads of code out there that has undefined order of
operations but is invariant w.r.t. said ordering and is therefore
correct.
Problem with immutables and Template typeof(this)
I have been trying to figure templates out...
template ExampleTemplate(T)
{
struct ExampleTemplate
{
T value;
// constructor
auto this(T value)
{
this.value = value;
return this;
}
// opAdd
typeof(this) opAdd(typeof(this) that) // immutable
{
typeof(this) result;
result.value = this.value + that.value;
return result;
}
}
}
alias ExampleTemplate!int Example;
immutable immutableEx = Example(1);
Example ex = Example(1);
Example ex2 = immutableEx + ex;
I get this error with mutbale opAdd:
example.d(27): Error: mutable method
example.ExampleTemplate!int.ExampleTemplate.opAdd is not
callable using a immutable object
I get this error with immutable opAdd
---~---+---~---=---~---+---~---
example.d(18): Error: cannot modify immutable expression
result.value
example.d(27): Error: template instance
example.ExampleTemplate!int error instantiating
I get that typeof(this) is immutable ExampleTemplate!int.
I can't find any way to cast immutable away because
typeof(this) is the only way I know to get the type.
Any help would be greatly appreciated!
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords protects your account.
Check it out at http://mysecurelogon.com/manager
Re: Problem with immutables and Template typeof(this)
On Sunday, 28 December 2014 at 22:07:31 UTC, AuoroP via
Digitalmars-d-learn wrote:
I have been trying to figure templates out...
template ExampleTemplate(T)
{
struct ExampleTemplate
{
T value;
// constructor
auto this(T value)
{
this.value = value;
return this;
}
Constructor should not have a return value.
// opAdd
typeof(this) opAdd(typeof(this) that) // immutable
{
typeof(this) result;
result.value = this.value + that.value;
return result;
}
}
}
alias ExampleTemplate!int Example;
immutable immutableEx = Example(1);
Example ex = Example(1);
Example ex2 = immutableEx + ex;
I get this error with mutbale opAdd:
example.d(27): Error: mutable method
example.ExampleTemplate!int.ExampleTemplate.opAdd is not
callable using a immutable object
This is because you can only call member functions that are
marked with immutable, if your instance is immutable.
pragma(msg, typeof(this)) will print the type of this at compile
time.
I get this error with immutable opAdd
---~---+---~---=---~---+---~---
example.d(18): Error: cannot modify immutable expression
result.value
example.d(27): Error: template instance
example.ExampleTemplate!int error instantiating
This is because typeof(this) is immutable.
I get that typeof(this) is immutable ExampleTemplate!int.
I can't find any way to cast immutable away because
typeof(this) is the only way I know to get the type.
Well, the type is ExampleTemplate. No reason not to write it
directly. If you cannot for whatever reason I currently do not
see: cast to Unqual!(typeof(this)).
See http://dlang.org/phobos/std_traits.html
Re: Problem with immutables and Template typeof(this)
On Sun, 28 Dec 2014 14:07:18 -0800
AuoroP via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
let me give you a riddle:
struct ExampleTemplate(T) {
T value;
auto opAdd (typeof(this) that) inout {
import std.traits : Unqual;
Unqual!(typeof(this)) result;
result.value = this.value+that.value;
return result;
}
}
alias ExampleTemplate!int Example;
void main () {
immutable immutableEx = Example(1);
Example ex = Example(1);
Example ex2 = immutableEx+ex;
}
i tend to give some explanations to my answers here, but i'm in a
strange mood today, so sorry, no explanations this time.
signature.asc
Description: PGP signature
Re: Problem with immutables and Template typeof(this)
On Sunday, 28 December 2014 at 22:07:31 UTC, AuoroP via
Digitalmars-d-learn wrote:
I have been trying to figure templates out...
template ExampleTemplate(T)
{
struct ExampleTemplate
{
T value;
// constructor
auto this(T value)
Constructors don't have return types.
{
this.value = value;
return this;
Constructors don't return.
}
// opAdd
typeof(this) opAdd(typeof(this) that) // immutable
{
typeof(this) result;
result.value = this.value + that.value;
return result;
}
}
}
alias ExampleTemplate!int Example;
immutable immutableEx = Example(1);
Example ex = Example(1);
Example ex2 = immutableEx + ex;
I get this error with mutbale opAdd:
example.d(27): Error: mutable method
example.ExampleTemplate!int.ExampleTemplate.opAdd is not
callable using a immutable object
I get this error with immutable opAdd
---~---+---~---=---~---+---~---
example.d(18): Error: cannot modify immutable expression
result.value
example.d(27): Error: template instance
example.ExampleTemplate!int error instantiating
I get that typeof(this) is immutable ExampleTemplate!int.
I can't find any way to cast immutable away because
typeof(this) is the only way I know to get the type.
The type is ExampleTemplate, so:
ExampleTemplate result;
But if you actually need to, you can use std.traits.Unqual to get
the unqualified version of a type:
import std.traits: Unqual;
Unqual!(typeof(this)) result;
Re: opDollar and length
On 28/12/14 19:21, Tobias Pankrath via Digitalmars-d-learn wrote: To allow slicing for types that don't have a length property but are terminated by a sentinel value, like null terminated strings or single linked lists. It's usefull for multi-dimensional containers as well. Ah, clear. Thanks very much. (Must remember to look into the multi-dimensional container issue in more detail, that looks like something worth understanding in depth.)
Re: Problem with immutables and Template typeof(this)
-Original Message-
From: digitalmars-d-learn@puremagic.com
Sent: Sun, 28 Dec 2014 22:18:43 +
To: digitalmars-d-learn@puremagic.com
Subject: Re: Problem with immutables and Template typeof(this)
On Sunday, 28 December 2014 at 22:07:31 UTC, AuoroP via
Digitalmars-d-learn wrote:
I have been trying to figure templates out...
template ExampleTemplate(T)
{
struct ExampleTemplate
{
T value;
// constructor
auto this(T value)
{
this.value = value;
return this;
}
Constructor should not have a return value.
Thank you!
// opAdd
typeof(this) opAdd(typeof(this) that) // immutable
{
typeof(this) result;
result.value = this.value + that.value;
return result;
}
}
}
alias ExampleTemplate!int Example;
immutable immutableEx = Example(1);
Example ex = Example(1);
Example ex2 = immutableEx + ex;
I get this error with mutbale opAdd:
example.d(27): Error: mutable method
example.ExampleTemplate!int.ExampleTemplate.opAdd is not
callable using a immutable object
This is because you can only call member functions that are
marked with immutable, if your instance is immutable.
pragma(msg, typeof(this)) will print the type of this at compile
time.
Thank you, that is easier than my method:
// opDbg
typeof(this) opDbg() immutable
{
writeln( typeof(this).stringof );
return this;
}
I get this error with immutable opAdd
---~---+---~---=---~---+---~---
example.d(18): Error: cannot modify immutable expression
result.value
example.d(27): Error: template instance
example.ExampleTemplate!int error instantiating
This is because typeof(this) is immutable.
I get that typeof(this) is immutable ExampleTemplate!int.
I can't find any way to cast immutable away because
typeof(this) is the only way I know to get the type.
Well, the type is ExampleTemplate. No reason not to write it
directly. If you cannot for whatever reason I currently do not
see: cast to Unqual!(typeof(this)).
See http://dlang.org/phobos/std_traits.html
I tried this and it works!!! I just don't get why it works. It /is/ a type but
it seems a parameter short of being useful! I definitely wouldn't have tried it
on my own so I'm really thankful for that!
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
Re: Problem with immutables and Template typeof(this)
-Original Message-
From: digitalmars-d-learn@puremagic.com
Sent: Sun, 28 Dec 2014 22:21:20 +
To: digitalmars-d-learn@puremagic.com
Subject: Re: Problem with immutables and Template typeof(this)
On Sunday, 28 December 2014 at 22:07:31 UTC, AuoroP via
Digitalmars-d-learn wrote:
I have been trying to figure templates out...
template ExampleTemplate(T)
{
struct ExampleTemplate
{
T value;
// constructor
auto this(T value)
I also wanted to thank you for your very helpful answer!
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth
Re: Need example of usage DerelictPQ
On Sunday, 28 December 2014 at 08:41:15 UTC, Suliman wrote: import postgres; import database; Those should include the package name: import arsd.postgres; Since it publicly imports the base clas, you don't need to import database yourself. (You do still need to pass all files to dmd though, your command line should remain the same. and getting next error: Those are protection errors because the package name isn't right, fix that and it should work (assuming you haven't modified the other source files) Also I can't understand why I do not need specify login and pass when I connection to DB? Postgresql authenticates based on what operating system user you're logged in as. You can change that in the server settings but normally the default works well.
Re: Data Frames in D - let's not wait for linear algebra; useful today in finance and Internet of Things
Laeeth - I am not sure exactly what your needs are but I have a fairly complete solution for generic multidimensional interfaces (template-based, bounds checked, RAII-ready, non-integer indices, the whole shebang) that I have been building. Anyway I don't want to spam the forum if I've missed the point of this discussion, but perhaps we could speak about it further over email and you could give me your opinion? I'm at vlevenf...@gmail.com
Re: xcb error for core.thread's Thread.join
On Monday, 29 December 2014 at 06:26:04 UTC, Jeremy DeHaan wrote: Hey all, I've never gotten any xcb errors with just regular D code before, but maybe I just haven't done anything that would have caused them. I can't say I actually know much about how these things work, but does D not use xcb when it does threading on Linux? I'm not really doing anything that I could call complicated. I am creating a secondary thread and just outputting some text to the console from both threads. The error itself seems to happen on a call to Thread.join, though I can't say why. Looks like it isn't the call to Thread.join, that was just a coincidence for my writeln debugging. If I have the second thread going it just happens.
Re: xcb error for core.thread's Thread.join
On Monday, 29 December 2014 at 06:34:02 UTC, Jeremy DeHaan wrote: On Monday, 29 December 2014 at 06:26:04 UTC, Jeremy DeHaan wrote: Hey all, I've never gotten any xcb errors with just regular D code before, but maybe I just haven't done anything that would have caused them. I can't say I actually know much about how these things work, but does D not use xcb when it does threading on Linux? I'm not really doing anything that I could call complicated. I am creating a secondary thread and just outputting some text to the console from both threads. The error itself seems to happen on a call to Thread.join, though I can't say why. Looks like it isn't the call to Thread.join, that was just a coincidence for my writeln debugging. If I have the second thread going it just happens. Not sure if this makes any difference, but I don't get any errors when I let the main thread sleep, but the main thread and secondary thread do not run simultaneously.
Re: xcb error for core.thread's Thread.join
On 29/12/2014 7:39 p.m., Jeremy DeHaan wrote: On Monday, 29 December 2014 at 06:34:02 UTC, Jeremy DeHaan wrote: On Monday, 29 December 2014 at 06:26:04 UTC, Jeremy DeHaan wrote: Hey all, I've never gotten any xcb errors with just regular D code before, but maybe I just haven't done anything that would have caused them. I can't say I actually know much about how these things work, but does D not use xcb when it does threading on Linux? I'm not really doing anything that I could call complicated. I am creating a secondary thread and just outputting some text to the console from both threads. The error itself seems to happen on a call to Thread.join, though I can't say why. Looks like it isn't the call to Thread.join, that was just a coincidence for my writeln debugging. If I have the second thread going it just happens. Not sure if this makes any difference, but I don't get any errors when I let the main thread sleep, but the main thread and secondary thread do not run simultaneously. XCB and xlib in general is not thread safe. They should only ever be called on one thread. Although I'm guessing you're not directly interfacing with it in which case that little tidbit isn't much use to you.
