Re: D + .NET
Only native libraries are more or less accessible from D, not .net. For .net you can use pinvoke (if you can build D dll) or IPC.
Re: How does laziness and UFCS interact?
On 03/10/2015 08:00 AM, John Colvin wrote:
On Tuesday, 10 March 2015 at 14:41:00 UTC, Logan Capaldo wrote:
On Monday, 9 March 2015 at 22:15:43 UTC, Ali Çehreli wrote:
You are right. I had the same observation at minute 11:27 below,
where I warn against UFCS with assumeWontThrow:
http://www.youtube.com/watch?feature=player_detailpagev=oF8K4-bieaw#t=687
Ali
Sorry, which is right?
You are right that it is confusing. :)
I know ifThrown is lazy, I'm curious about the
amount of the expression that is evaluated lazily.
a.b().c().assumeWontThrow vs. a.b().c().assumeWontThrow
^--+^^-^
| |
+- lazy? +- lazy?
As John Colvin said, the first one is right. A test:
import std.stdio;
struct S
{}
S a(S s)
{
writeln(entered a);
return s;
}
S b(S s)
{
writeln(entered b);
return s;
}
void lazily(T)(lazy T expression)
{
writeln(entered lazily);
expression();
}
void main()
{
S().a.b.lazily;
}
Outputs
entered lazily
entered a
entered b
The video seems to say don't use lazy functions with UFCS because you
might think the lazy part gets evaluated first, when it does not.
Seems reasonable, although I don't know it's any different than
assumeWontThrow(f()).
You are right again. :) However, putting the lazy-taking function
outside the whole expression makes it visible right away, making easy
for me to realize that the execution order may be different from common
chains.
Ali
Re: D + .NET
On 2015-03-11 14:30, Sativa wrote: Can you point out where it says anything about wpf or .NET? I'm having trouble finding it. I even searched for .net and wpf but still no luck ;/ Maybe you posted the wrong link by accident? You did mention win32 ;) For OS X Cocoa is the GUI framework. To access that you need to interface with Objective-C. That can either be done using the Objective-C runtime library [1], available from C. This is very tedious and verbose, or wait for this pull request [2] which will add support for linking with Objective-C. [1] https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ObjCRuntimeRef/index.html [2] https://github.com/D-Programming-Language/dmd/pull/4321 -- /Jacob Carlborg
Re: How to find the cause of crash?
I want to know how to locate the position of crashing in dlang? for example: there is stack dump in c, exception stack in java, they could help to locate the root of problems.
Looking for MQTT client library
I'm looking a MQTT [0] client library written in D, if it exists. Anyone know of any? I found the great Atila Neves MQTT broker (server) [1], and some C/C++ libraries [2], so, possible solutions are: a. Write a native D library from scratch b. Adapt/copy some parts of [1] to convert from server to client c. Create a binding from [2] Anyone has other idea that I could use to create this myself? Thanks [0]http://mqtt.org/ [1]https://github.com/atilaneves/mqtt [2]http://www.eclipse.org/paho/clients/c/
Re: How to use UFCS and std.algorithm.sort?
On 03/10/2015 01:40 AM, Jonathan M Davis via Digitalmars-d-learn wrote: .sort on an array is going to use the built-in sort property. You need to use parens if you want to use the function in std.algorithm with an array and UFCS, e.g. arr.sort(); Didn't know that. Nice! Another option is to use renamed imports[1] but it is hard to come up with an acceptable name other than sort: import std.algorithm: algSort = sort, uniq, map; // -- HERE // ... string[] result = arr .map!(n = n) // minified .array .algSort // -- HERE .uniq .array; Ali [1] http://dlang.org/module.html
Re: enum and static if
On Wed, 11 Mar 2015 13:48:45 +, Namespace wrote:
This code does not work:
enum Test {
Foo,
static if (__VERSION__ = 2067)
Bar,
}
Quatz
}
Any chance that this could work?
nope. `static if` is statement, so it works only where statement is
allowed. the same is true for `version`. this is by design.
signature.asc
Description: PGP signature
Re: D + .NET
You can also try to expose COM-accessible .net interface and use it through COM in D.
Re: Bypass the protection level
On Wednesday, 11 March 2015 at 15:22:43 UTC, Ali Çehreli wrote: On 03/11/2015 04:40 AM, Namespace wrote: I can call draw on Drawable, because it is declared public and I cannot call draw on Sprite because it is declared protected (this is already a bit weird, why can I redeclare the interface method draw as protected?) It is the same in C++. but I can call the protected draw method from Sprite through Drawable. Is this intended? As far as I know, yes it's intended and again the same in C++. Ali o.O nice to know. Thank you.
Re: auto function attributes based on type
On Thu, 12 Mar 2015 04:51:40 +, amber wrote:
On Thursday, 12 March 2015 at 04:04:28 UTC, weaselcat wrote:
On Thursday, 12 March 2015 at 03:12:15 UTC, amber wrote:
...
http://dlang.org/function.html#function-attribute-inference might be a
good read if you haven't read it already.
I did read it but didn't really understand it, so I've come to D.learn
for more help.
I think it means I can just write the function like so:
struct S(T) {
someFunc(int i) {// impl}
}
and if possible it will be pure, nothrow, @safe and @nogc.
yes. all templated functions (and `someFunc()` is templated due to `S`
being templated) are subjects of attribute inference. due to this fact
people sometimes writing even free functions as argument-less templates,
void freeFunc() (...) { ... }
so compiler will infer attributes for `freeFunc()`. this has almost no
cost, as compiler will merge all produced templates into one.
signature.asc
Description: PGP signature
Re: is eC alot like D?
On Wed, 11 Mar 2015 19:26:13 -0700, Parke via Digitalmars-d-learn wrote: On Wed, 11 Mar 2015 06:22:32 +, sclytrack wrote: - You can include C library headers directly in your .ec code, without any special keyword (like extern C in C++) On Wed, Mar 11, 2015 at 1:59 AM, ketmar via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: either i missed something, misunderstood what he means or he is simply wrong. i remember that there is no CPP macro processor in eC, so... oops. why my C header is not working?! Maybe the eC compiler invokes a C compiler to do the preprocessing. and then we have things like `static inline` functions and many other quirks. ah, and alot of standard C headers included, which are platform- dependent, by the way. so the only way to make this work is to have full- featured native C compiler inside. signature.asc Description: PGP signature
Re: D + .NET
On Wednesday, 11 March 2015 at 13:30:27 UTC, Sativa wrote: On Wednesday, 11 March 2015 at 08:45:15 UTC, Kagamin wrote: http://wiki.dlang.org/Libraries_and_Frameworks#GUI_Libraries Can you point out where it says anything about wpf or .NET? I'm having trouble finding it. I even searched for .net and wpf but still no luck ;/ Maybe you posted the wrong link by accident? .net can also expose and call C API in mixed code assemblies.
Re: moving from c++ to D is easy?
On Thu, 12 Mar 2015 13:01:29 +, ayush wrote: Is D a lot like c++ ? I am currently midway through learning c++ and I also want to learn D . So should i focus on one or learn both together? Will I find learning D easy if I already know c++ ? D is like C++, but made by human beings for human beings. and C++ is made by martians for monkeys. signature.asc Description: PGP signature
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:01:31 UTC, ayush wrote: Is D a lot like c++? Enough. So should i focus on one or learn both together? You can study both together, although it is better to focus on one. Will I find learning D easy if I already know c++? Yes.
Re: moving from c++ to D is easy?
On Thu, 12 Mar 2015 13:35:18 + ayush via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Thursday, 12 March 2015 at 13:13:40 UTC, Dennis Ritchie wrote: On Thursday, 12 March 2015 at 13:01:31 UTC, ayush wrote: Is D a lot like c++? Enough. So should i focus on one or learn both together? You can study both together, although it is better to focus on one. Will I find learning D easy if I already know c++? Yes. So on which language should I focus(learn) first D is much easier to learn so I will start with it. And then you can try learn C++ if you still want and need it.
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:13:40 UTC, Dennis Ritchie wrote: On Thursday, 12 March 2015 at 13:01:31 UTC, ayush wrote: Is D a lot like c++? Enough. So should i focus on one or learn both together? You can study both together, although it is better to focus on one. Will I find learning D easy if I already know c++? Yes. So on which language should I focus(learn) first
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:01:31 UTC, ayush wrote: Is D a lot like c++ ? I am currently midway through learning c++ and I also want to learn D . So should i focus on one or learn both together? Will I find learning D easy if I already know c++ ? D is very much like C++, but the biggest issue I found moving from C++ to D was trying to apply C++ idioms that only existed to work around ugly C++ warts(i.e, CRTP)
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:44:50 UTC, Daniel Kozák wrote: D is much easier to learn so I will start with it. And then you can try learn C++ if you still want and need it. Yes, but in D for beginners little literature, so I would recommend starting with C++.
Re: moving from c++ to D is easy?
On Thu, 12 Mar 2015 13:56:28 +, Dennis Ritchie wrote: On Thursday, 12 March 2015 at 13:44:50 UTC, Daniel Kozák wrote: D is much easier to learn so I will start with it. And then you can try learn C++ if you still want and need it. Yes, but in D for beginners little literature, so I would recommend starting with C++. there are alot of books on C++ 'cause C++ is insanely complicated and inconsistend. D design is *MUCH* better, so D doesn't need so many books teaching arcane art of programming. signature.asc Description: PGP signature
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 13:56:29 UTC, Dennis Ritchie wrote: On Thursday, 12 March 2015 at 13:44:50 UTC, Daniel Kozák wrote: D is much easier to learn so I will start with it. And then you can try learn C++ if you still want and need it. Yes, but in D for beginners little literature, so I would recommend starting with C++. There is no need for dozens of books. I would even go as far as to say that the existing ones are more than enough. http://wiki.dlang.org/Books
Re: Memoization in compile-time
On 13/03/2015 2:23 p.m., Dennis Ritchie wrote:
Is it possible to run this code in compile-time?
import std.stdio, std.functional;
ulong fact(ulong n)
{
alias mfact = memoize!fact;
return n 2 ? 1 : n * mfact(n - 1);
}
void main() {
writeln(fact(10));
}
In CommonLisp variable *factorial-cache* available in CT, and RT.
Moreover, in the compiler environment of your *factorial-cache* and RT.
Thus we memoires as calculations in CT (constants), and RT.
(eval-always
(defparameter *factorial-cache* (make-hash-table))
(defun factorial (n)
(if ( n 1)
1
(setf (gethash n *factorial-cache*) (* n (factorial (1- n)))
(define-compiler-macro factorial (whole whole n)
(if (constantp n) (factorial n) whole))
Here is an example I have in my Developing with compile time in mind
book[0]:
size_t factorial(size_t n) pure {
assert(n 11);
if (n == 0) {
return 1;
} else {
return n * factorial(n - 1);
}
}
static assert(factorial(5) == 120);
Notice how it is in a static assert? Yeah that is at compile time.
You could assign it to e.g. an enum. Or force it over using
meta-programming.
If you haven't already, I would strongly recommend that you read my book
on the subject.
[0] https://leanpub.com/ctfe
Re: chaining splitters
Yes. That's it! Thanks a lot.
On Wednesday, 11 March 2015 at 09:29:12 UTC, Dave S wrote:
On Wednesday, 11 March 2015 at 00:00:39 UTC, dnoob wrote:
Hello,
I am parsing some text and I have the following;
string text = some very long text;
foreach(line; splitter(text, [13, 10]))
{
foreach(record; splitter(line, '*'))
{
foreach(field; splitter(record, '='))
{
foreach(value; splitter(field, ','))
{
// do something...
}
}
}
}
I know there is a better way to do that but I'm a total D noob.
Thanks!
You can use std.algorithm's map to apply some function to all
the
items in a range:
---
import std.stdio, std.algorithm;
void main()
{
string text = foo*bar=qux\r\nHello*world!\r\nApril,May,June;
auto lines = splitter(text, \r\n);
auto records = map!(a = splitter(a, '*'))(lines).joiner();
auto fields = map!(a = splitter(a, '='))(records).joiner();
auto values = map!(a = splitter(a, ','))(fields).joiner();
foreach (value; values)
{
writeln(value);
}
}
---
This produces the output:
foo
bar
qux
Hello
world!
April
May
June
The joiner() is necessary because when you pass a range of
strings to splitter using map the result is a range of ranges of
strings. joiner() joins these together into one range of
strings.
Consider this code, for example:
---
string str = foo*bar=qux\r\nHello*world!\r\nApril,May,June;
auto lines = splitter(str, [13, 10]);
auto result = map!(a = splitter(a, '*'))(lines);
auto tokens = result.joiner();
---
The contents of result are:
[foo, bar=qux]
[Hello, world!]
[April,May,June]
The contents of tokens are:
[foo, bar=qux, Hello, world!, April,May,June]
I am not a D expert by any means so there it's possible there is
another way that I am not aware of.
Re: is eC alot like D?
To confirm guys eC does support C preprocessing. The C preprocessor is invoked before the eC compiler does its parsing. And all native C headers should work fine as well, although there might be some portability issues on more obscure platforms which have not yet been tested which would require attention, but as you can see at https://packages.debian.org/jessie/libecerecom0 it works fine on most popular platforms. eC tries to be a superset of C as much possible, with only a few keyword clashes like 'class' as an exception. Best regards, -Jerome On Thursday, 12 March 2015 at 11:02:11 UTC, ketmar wrote: On Wed, 11 Mar 2015 19:26:13 -0700, Parke via Digitalmars-d-learn wrote: On Wed, 11 Mar 2015 06:22:32 +, sclytrack wrote: - You can include C library headers directly in your .ec code, without any special keyword (like extern C in C++) On Wed, Mar 11, 2015 at 1:59 AM, ketmar via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: either i missed something, misunderstood what he means or he is simply wrong. i remember that there is no CPP macro processor in eC, so... oops. why my C header is not working?! Maybe the eC compiler invokes a C compiler to do the preprocessing. and then we have things like `static inline` functions and many other quirks. ah, and alot of standard C headers included, which are platform- dependent, by the way. so the only way to make this work is to have full- featured native C compiler inside.
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 14:47:22 UTC, ketmar wrote: there are alot of books on C++ 'cause C++ is insanely complicated and inconsistend. D design is *MUCH* better, so D doesn't need so many books teaching arcane art of programming. Well, in principle, can be started with a D, but personally, I started actually with ANSI C.
Re: Looking for MQTT client library
Those are basically your options. You could wrap Mosquitto (a C implementation), but I'd just use the existing MQTT broker code. Then again, I would say that. :) Atila On Thursday, 12 March 2015 at 07:59:55 UTC, o3o wrote: I'm looking a MQTT [0] client library written in D, if it exists. Anyone know of any? I found the great Atila Neves MQTT broker (server) [1], and some C/C++ libraries [2], so, possible solutions are: a. Write a native D library from scratch b. Adapt/copy some parts of [1] to convert from server to client c. Create a binding from [2] Anyone has other idea that I could use to create this myself? Thanks [0]http://mqtt.org/ [1]https://github.com/atilaneves/mqtt [2]http://www.eclipse.org/paho/clients/c/
Re: Looking for MQTT client library
My preferred option is b. that is convert your MQTT broker to MQTT client. I'm not a MQTT expert, so, in your opinion what parts of your code should I change? (i.e. message module should be the same, peraphs module stream...) Thanks for your support (and also for your unit-threaded project!) On Thursday, 12 March 2015 at 15:03:13 UTC, Atila Neves wrote: Those are basically your options. You could wrap Mosquitto (a C implementation), but I'd just use the existing MQTT broker code. Then again, I would say that. :) Atila
Re: Template Parameter Deduction
On Wednesday, 11 March 2015 at 23:04:15 UTC, Ali Çehreli wrote:
On 03/11/2015 03:44 PM, Paul D Anderson wrote:
This used to work in D2.065:
given
1) public T mul(T)(in T x, in T y,
Context context = T.context) if (isDecimal!T)
// one template parameter for the two input values
and
2) public T mul(T, U)(in T x, U n, Context context = T.context)
if (isDecimal!T isIntegral!U)
// two different template parameters for the two input
values
then
3) dec9 arg1 = dec9(1.20);
long arg2 = 3;
result = mul(arg1, arg2);
// correctly deduced function
But now (D2.066.1) either 1) has to be changed to
1) public T mul(T, U)(in T x, U y, Context context = T.context)
if (isDecimal!T isDecimal!U)
// two identical template parameters for the two input
values
or 3) has to be changed to
3) dec9 arg1 = dec9(1.20);
long arg2 = 3;
result = mul!(dec9,long)(arg1, arg2);
// template parameters have to be made explicit
Is this expecded behavior?
Paul
Hint: It makes it much simpler to work with complete code. The
following code took a while for me to put together:
template isDecimal(T)
{
enum isDecimal = true;
}
template isIntegral(T)
{
enum isIntegral = true;
}
public T mul(T)(in T x, in T y,
Context context = T.context) if (isDecimal!T)
// one template parameter for the two input values
{
return x;
}
alias Context = int;
public T mul(T, U)(in T x, U n, Context context = T.context)
if (isDecimal!T isIntegral!U)
// two different template parameters for the two input
values
{
return x;
}
struct dec9
{
string s;
enum context = 42;
}
void main()
{
dec9 arg1 = dec9(1.20);
long arg2 = 3;
dec9 result = mul(arg1, arg2);
// correctly deduced function
}
Yes, it fails with 2.066.1 but compiles fine with git head.
Ali
Thanks to you and John for taking the time to work this out. I
didn't mean for anyone to rebuild the example -- I was just
hoping there was a quick answer based on known language changes.
I should have included complete example code.
At any rate, it looks like there is a hiccup in the template
parameter deduction code and that it is being fixed. And it's
easy to work around. I'll dig a little deeper to see if I can
find a related bug report.
Paul
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 18:57:51 UTC, Ali Çehreli wrote:
On 03/12/2015 06:01 AM, ayush wrote:
Is D a lot like c++ ?
I came to D from C++. I remember the following being notable
differences:
- In D, classes have reference semantics. I quickly realized
that this is not an issue because so many of my C++ types were
hand-reference-typified :p by this idiom, almost everywhere:
class C { /* ... */ };
typedef boost::shared_ptrC CPtr;
void foo(CPtr c);
This is a common mistake. In 99 percent of cases you want to use
a std::unique_ptr. std::shared_ptr is rarely common and often an
indication of an error in design. In general, there is exactly
one owner only.
But I think you know that already. :)
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 18:57:51 UTC, Ali Çehreli wrote: If you are a mortal like myself, you may find out years later that you are still at the midway point. Happened to me several times when I was learning C++. :) О, yeah.
Re: moving from c++ to D is easy?
On 03/12/2015 06:01 AM, ayush wrote:
Is D a lot like c++ ?
I came to D from C++. I remember the following being notable differences:
- In D, classes have reference semantics. I quickly realized that this
is not an issue because so many of my C++ types were
hand-reference-typified :p by this idiom, almost everywhere:
class C { /* ... */ };
typedef boost::shared_ptrC CPtr;
void foo(CPtr c);
- Garbage collector took longer to get used to. There are some issues
with the spec or implementation that some objects may never be
destructed (or is it finalized?).
Other than issues like that, everything in D feels like a fresh air.
I am currently midway through learning c++
If you are a mortal like myself, you may find out years later that you
are still at the midway point. Happened to me several times when I was
learning C++. :)
and I also want to learn D . So should i focus on one or learn
both together?
Economically, C++ may make more sense. But if you are learning just for
yourself, perhaps for fun, then I recommend D.
Will I find learning D easy if I already know c++ ?
I think so.
Ali
moving from c++ to D is easy?
Is D a lot like c++ ? I am currently midway through learning c++ and I also want to learn D . So should i focus on one or learn both together? Will I find learning D easy if I already know c++ ?
Re: moving from c++ to D is easy?
On 03/12/2015 01:19 PM, Namespace wrote:
On Thursday, 12 March 2015 at 18:57:51 UTC, Ali Çehreli wrote:
On 03/12/2015 06:01 AM, ayush wrote:
Is D a lot like c++ ?
I came to D from C++. I remember the following being notable
differences:
- In D, classes have reference semantics. I quickly realized that this
is not an issue because so many of my C++ types were
hand-reference-typified :p by this idiom, almost everywhere:
class C { /* ... */ };
typedef boost::shared_ptrC CPtr;
void foo(CPtr c);
This is a common mistake. In 99 percent of cases you want to use a
std::unique_ptr.
Agreed. Here is an excerpt from a comment from one of our header files:
We could not use boost::unique_ptr because the version of the Boost
library that we currently use does not include it.
std::shared_ptr is rarely common and often an indication of an
error in design. In general, there is exactly one owner only.
Of course. We had definitions like the following as well, where the C
objects are stored in:
typedef vectorCPtr MyCs;
But I think you know that already. :)
I think so. :) Maybe we should pass weak_ptrs around instead of
shared_ptr. Anyway... That's old code and this is a D newsgroup.
Ali
Re: moving from c++ to D is easy?
On Thursday, 12 March 2015 at 21:41:07 UTC, Ali Çehreli wrote:
On 03/12/2015 01:19 PM, Namespace wrote:
On Thursday, 12 March 2015 at 18:57:51 UTC, Ali Çehreli wrote:
On 03/12/2015 06:01 AM, ayush wrote:
Is D a lot like c++ ?
I came to D from C++. I remember the following being notable
differences:
- In D, classes have reference semantics. I quickly realized
that this
is not an issue because so many of my C++ types were
hand-reference-typified :p by this idiom, almost everywhere:
class C { /* ... */ };
typedef boost::shared_ptrC CPtr;
void foo(CPtr c);
This is a common mistake. In 99 percent of cases you want to
use a
std::unique_ptr.
Agreed. Here is an excerpt from a comment from one of our
header files:
We could not use boost::unique_ptr because the version of the
Boost library that we currently use does not include it.
std::shared_ptr is rarely common and often an indication of an
error in design. In general, there is exactly one owner only.
Of course. We had definitions like the following as well, where
the C objects are stored in:
typedef vectorCPtr MyCs;
But I think you know that already. :)
I think so. :) Maybe we should pass weak_ptrs around instead of
shared_ptr.
You could also pass raw pointers around. Since they have no owner
it's fine. Or references.
Anyway... That's old code and this is a D newsgroup.
Ali
Agreed.
Re: Looking for MQTT client library
If it isn't on http://code.dlang.org it is unlikely to exist in easy to use form. Starting with C bindings is probably the easiest approach - you may want to check out https://github.com/jacob-carlborg/dstep if you haven't already.
vibe.d crashs when forwarding a stream to another?
I posted in vibe.d forum, no one replied . Help me please: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/24458/
Memoization in compile-time
Is it possible to run this code in compile-time?
import std.stdio, std.functional;
ulong fact(ulong n)
{
alias mfact = memoize!fact;
return n 2 ? 1 : n * mfact(n - 1);
}
void main() {
writeln(fact(10));
}
In CommonLisp variable *factorial-cache* available in CT, and RT.
Moreover, in the compiler environment of your *factorial-cache*
and RT. Thus we memoires as calculations in CT (constants), and
RT.
(eval-always
(defparameter *factorial-cache* (make-hash-table))
(defun factorial (n)
(if ( n 1)
1
(setf (gethash n *factorial-cache*) (* n (factorial (1-
n)))
(define-compiler-macro factorial (whole whole n)
(if (constantp n) (factorial n) whole))
Re: embedding Pyd in Windows program
On 03/11/2015 07:59 PM, Matt wrote: Right, copying site.py into my program's working dir sorts out the missing module error, but I now get a syntax error: file=sys.stderr) ^ SyntaxError: invalid syntax Error executing command run: Program exited with code 1 I googled this, and apparently it's caused by an older interpreter. The only files I have transferred over are: python3.DLL python3.LIB python34.LIB Does anyone have any idea what I might be doing wrong, or how I can fix this? I'm guessing your python path is screwed up. In your embedded python, import sys print (sys.path) make sure everything is pointing where it should. Failing that, are you using the correct dub configuration? without checking, I believe it defaults to python 2.7. Failing that, you transferred python3.dll from somewhere to somewhere? I believe pyd links to \windows\system32\python3.dll or some such. At least, I think that's where those lib files point to. not sure. If that is an issue and you want to use your own lib files, you will need to generate OMF files from them.
Re: auto function attributes based on type
On Thursday, 12 March 2015 at 05:01:50 UTC, amber wrote:
On Thursday, 12 March 2015 at 04:51:42 UTC, amber wrote:
On Thursday, 12 March 2015 at 04:04:28 UTC, weaselcat wrote:
On Thursday, 12 March 2015 at 03:12:15 UTC, amber wrote:
...
http://dlang.org/function.html#function-attribute-inference
might be a good read if you haven't read it already.
I did read it but didn't really understand it, so I've come to
D.learn for more help.
I think it means I can just write the function like so:
struct S(T) {
someFunc(int i) {// impl}
}
and if possible it will be pure, nothrow, @safe and @nogc.
thanks,
amber
This works nicely after checking with
__traits(getFunctionAttributes, S!T.someFunc)
Very cool :)
bye,
amber
You can also use the __PRETTY_FUNCTION__ keyword to display
information about a function.
http://dlang.org/traits.html#specialkeywords
