I'm using Qt/C++ on a Mac. I want to try my hand at making a
dylib in D that can receive a C++ string, reverse it, and respond
with the result back to Qt/C++.
Are there any easy tutorials out there with something simple like
that?
You probably want me to type some code so that I showed that
On 09/25/2015 08:22 PM, Enjoys Math wrote:
Init:
programResultsQ = heapify!(compareResults,
Array!(Results!(O,I)))(Array!(Results!(O,I))([Results!(O,I)()]), 1);
Decl:
alias ProgramResultsQueue(O,I) = BinaryHeap!(Array!(Results!(O,I)),
compareResults);
Error:
assert error in std.container.arr
Oops found it my self.
I had to use
auto x = foo();
I tried your code as this and it doesn't work.
#!/usr/bin/rdmd -O
import std.stdio;
struct S {
int a;
@disable this(this);
};
S foo() {
S v;
v.a = 1;
writeln(&v);
return v;
}
void main()
{
S x;
x = foo();
writeln(&x);
}
I even tried with dmd -O without su
On Monday, 28 September 2015 at 04:55:30 UTC, tcak wrote:
On Sunday, 27 September 2015 at 23:56:10 UTC, holo wrote:
Hello
Im trying to execute commands on server side. Here is my
server based on other example from forum:
[...]
You are comparing whole buffer to "exit"
I changed my conditi
On Monday 28 September 2015 11:59, holo wrote:
> I changed my condition to:
>
> if(to!string(buffer[0..received]) == "exit")
> {
>
> break;
> }
>
>
> But it still dint help.
The client probably sends a newline; i.e. buffer[0 .. received] is "exit\n".
On Monday 28 September 2015 12:40, anonymous wrote:
> The client probably sends a newline; i.e. buffer[0 .. received] is
> "exit\n".
Or more likely it's "exit\r\n".
On Sat, 2015-09-26 at 10:46 +, John Colvin via Digitalmars-d-learn
wrote:
> […]
I guess the summary is: it's a breaking change, so do it. No we can't
do that it's a breaking change.
Seems lame given all the other breaking changes that have been. Sad
given that reduce is probably the single m
On Sat, 2015-09-26 at 12:32 +, Zoidberg via Digitalmars-d-learn
wrote:
> > Here's a correct version:
> >
> > import std.parallelism, std.range, std.stdio, core.atomic;
> > void main()
> > {
> > shared ulong i = 0;
> > foreach (f; parallel(iota(1, 100+1)))
> > {
> > i.at
On Sat, 2015-09-26 at 14:33 +0200, anonymous via Digitalmars-d-learn
wrote:
> […]
> I'm pretty sure atomicOp is faster, though.
Rough and ready anecdotal evidence would indicate that this is a
reasonable statement, by quite a long way. However a proper benchmark
is needed for statistical significa
On Sat, 2015-09-26 at 15:56 +, Jay Norwood via Digitalmars-d-learn
wrote:
> std.parallelism.reduce documentation provides an example of a
> parallel sum.
>
> This works:
> auto sum3 = taskPool.reduce!"a + b"(iota(1.0,101.0));
>
> This results in a compile error:
> auto sum3 = taskPool.re
On Sat, 2015-09-26 at 17:20 +, Jay Norwood via Digitalmars-d-learn
wrote:
> This is a work-around to get a ulong result without having the
> ulong as the range variable.
>
> ulong getTerm(int i)
> {
> return i;
> }
> auto sum4 = taskPool.reduce!"a +
> b"(std.algorithm.map!getTerm(iota(10
On Fri, 2015-09-25 at 18:45 +, Meta via Digitalmars-d-learn wrote:
> […]
>
> The main difference is that "method call" style is more amenable
> to chaining (and IMO, it looks cleaner as you don't have nesting
> parentheses.
I guess coming from Clojure I was less worried about Lisp-style cod
On Monday, 28 September 2015 at 11:04:56 UTC, Russel Winder wrote:
On Sat, 2015-09-26 at 10:46 +, John Colvin via
Digitalmars-d-learn wrote:
[…]
I guess the summary is: it's a breaking change, so do it. No we
can't do that it's a breaking change.
Seems lame given all the other breaking
On Monday, 28 September 2015 at 11:31:33 UTC, Russel Winder wrote:
On Sat, 2015-09-26 at 14:33 +0200, anonymous via
Digitalmars-d-learn wrote:
[…]
I'm pretty sure atomicOp is faster, though.
Rough and ready anecdotal evidence would indicate that this is
a reasonable statement, by quite a long
On Monday, 28 September 2015 at 10:52:07 UTC, anonymous wrote:
On Monday 28 September 2015 12:40, anonymous wrote:
The client probably sends a newline; i.e. buffer[0 ..
received] is "exit\n".
Or more likely it's "exit\r\n".
I changed condition to:
if(to!string(buffer[0..received]) == "exit
I hadn't answered as I do not have answers to the questions you ask. My
reason: people should not be doing their codes using these low-level
shared memory techniques. Data parallel things should be using the
std.parallelism module. Dataflow-style things should be using spawn and
channels – akin to
On Mon, 2015-09-28 at 11:37 +, John Colvin via Digitalmars-d-learn
wrote:
>
[…]
> My thoughts exactly, even though it was partly me that pointed
> out the breaking changes...
Curses, if no-one had pointed out it was breaking maybe no-one would
have noticed, and just made the change?
> I sti
On Mon, 2015-09-28 at 11:38 +, John Colvin via Digitalmars-d-learn
wrote:
> […]
>
> It would be really great if someone knowledgable did a full
> review of std.parallelism to find out the answer, hint, hint...
> :)
Indeed, I would love to be able to do this. However I don't have time
in th
As a single data point:
== anonymous_fix.d ==
5050
real0m0.168s
user0m0.200s
sys 0m0.380s
== colvin_fix.d ==
5050
real0m0.036s
user0m0.124s
sys 0m0.000s
== norwood_reduce.d
On Monday, 28 September 2015 at 12:18:28 UTC, Russel Winder wrote:
As a single data point:
== anonymous_fix.d == 5050
real0m0.168s
user0m0.200s
sys 0m0.380s
== colvin_fix.d ==
5050
real0m0.036s
user0m
On Monday, 28 September 2015 at 11:44:32 UTC, holo wrote:
if(to!string(buffer[0..received]) == "exit\n")
You shouldn't need that to!string by the way. I believe that will
work just comparing the buffer directly.
Converting to string is more important when you are storing a
copy than just co
On Mon, 2015-09-28 at 12:46 +, John Colvin via Digitalmars-d-learn
wrote:
> […]
>
> Pretty much as expected. Locks are slow, shared accumulators
> suck, much better to write to thread local and then merge.
Quite. Dataflow is where the parallel action is. (Except for those
writing concurrency
On Tuesday, 22 September 2015 at 09:38:12 UTC, thedeemon wrote:
On Monday, 21 September 2015 at 15:00:24 UTC, ponce wrote:
All in the title.
DMD 64-bit links with the VS linker.
Do users need to install the VS redistributable libraries?
I think they don't.
Generated .exe seems to depend only
http://wiki.dlang.org/Vision/2015H1 C++ integration was planned
to be available by the end of 2015. May be too optimistic still.
On Monday, 28 September 2015 at 15:10:25 UTC, ponce wrote:
On Tuesday, 22 September 2015 at 09:38:12 UTC, thedeemon wrote:
On Monday, 21 September 2015 at 15:00:24 UTC, ponce wrote:
All in the title.
DMD 64-bit links with the VS linker.
Do users need to install the VS redistributable libraries
On Monday, 28 September 2015 at 16:01:54 UTC, Sebastiaan Koppe
wrote:
On Monday, 28 September 2015 at 15:10:25 UTC, ponce wrote:
On Tuesday, 22 September 2015 at 09:38:12 UTC, thedeemon wrote:
On Monday, 21 September 2015 at 15:00:24 UTC, ponce wrote:
All in the title.
DMD 64-bit links with t
Maybe LDC uses dynamic linking by default and DMD static one,
same as on Linux?
On 2015-09-28 09:08, Mike McKee wrote:
I'm using Qt/C++ on a Mac. I want to try my hand at making a dylib in D
Dynamic libraries are not officially supported on OS X.
--
/Jacob Carlborg
Maybe LDC uses dynamic linking by default and DMD static one,
same as on Linux?
Yes, LDC does use dynamic linking by default (as MSVC iirc).
Static linking can be enabled by providing the
-DLINK_WITH_MSVCRT=OFF switch to the CMake command.
OK, but why does that need to happen? I don't get wh
On Sunday, 27 September 2015 at 22:55:38 UTC, Johannes Loher
wrote:
On Saturday, 26 September 2015 at 18:27:52 UTC, Mike McKee
wrote:
On Saturday, 26 September 2015 at 10:31:13 UTC, wobbles wrote:
Have you installed dkit for sublime?
As in?
https://github.com/yazd/DKit
Looks like it's alpha
On Monday, 28 September 2015 at 15:10:25 UTC, ponce wrote:
Does it also affect executable made with DMD and linked with MS
linker?
Just tested: no.
On Sunday, 27 September 2015 at 05:52:26 UTC, Jack Stouffer wrote:
Please make an issue on https://issues.dlang.org and I'll take
a look a this later. Most of the functions in std.conv are
templated so it must be some internal function that's not
properly annotated, or it's using manual memory
Is this intended or known issue ? It works with 2.066.
SList!int gslist = [1,2,3,4,5,6]; // broken since 2.067
// Error: reinterpreting cast from NodeWithoutPayload* to Node* is not
supported in CTFE
DList!int gdlist = [1,2,3,4,5,6]; // broken since 2.067
// Error: non-constant expression ...
vo
On 09/28/2015 02:15 PM, Martin Krejcirik wrote:
Is this intended or known issue ? It works with 2.066.
SList!int gslist = [1,2,3,4,5,6]; // broken since 2.067
// Error: reinterpreting cast from NodeWithoutPayload* to Node* is not
supported in CTFE
DList!int gdlist = [1,2,3,4,5,6]; // broken sin
On Saturday, 26 September 2015 at 15:56:54 UTC, Jay Norwood wrote:
This results in a compile error:
auto sum3 = taskPool.reduce!"a + b"(iota(1UL,101UL));
I believe there was discussion of this problem recently ...
https://issues.dlang.org/show_bug.cgi?id=14832
https://issues.dlang.org/sho
On Monday, 28 September 2015 at 11:47:38 UTC, Russel Winder wrote:
I hadn't answered as I do not have answers to the questions you
ask. My reason: people should not be doing their codes using
these low-level shared memory techniques. Data parallel things
should be using the std.parallelism modu
On Monday, 28 September 2015 at 13:01:25 UTC, Adam D. Ruppe wrote:
On Monday, 28 September 2015 at 11:44:32 UTC, holo wrote:
if(to!string(buffer[0..received]) == "exit\n")
You shouldn't need that to!string by the way. I believe that
will work just comparing the buffer directly.
Converting t
so I have a bunch of enums (0 .. n) that i also want to represent
as flags ( 1 << n foreach n ). Is there anyway to do this other
than a string mixin?
use like:
enum blah
{
foo,
bar,
baz,
}
alias blahFlags = EnumToFlags!blah;
static assert(blahFlags.baz == 1 << blah.baz)
On Tuesday, 29 September 2015 at 03:31:44 UTC, Nicholas Wilson
wrote:
so I have a bunch of enums (0 .. n) that i also want to
represent as flags ( 1 << n foreach n ). Is there anyway to do
this other than a string mixin?
You could cheat with operator overloading:
enum blah {
40 matches
Mail list logo
