Re: Is D a good choice for embedding python/octave/julia
On 03/13/2016 02:36 PM, Laeeth Isharc wrote:
InterpContext context = new InterpContext();
context.py_stmts(outdent("
import numpy
a = numpy.eye(2, dtype='complex128')
"));
context.a.to_d!(Complex!double[][] )();
nitpicking, but the outdent is unnecessary, py_stmts calls it.
hm. maybe that should be documented..
Re: Calling python code from D
On Thursday, 25 February 2016 at 21:40:45 UTC, Wyatt wrote:
I have a project I started in Python before I realised I really
don't enjoy Python. It's been on the back-burner for a few
years and I'd like to start again in D, but there's a
particular python module (Mutagen) that I outright refuse to
reimplement. What's the state of the art in calling Python
code from D?
I have a hunch PyD fits somewhere in this equation, but the
documentation is pretty sparse, and what little I can find
about this area makes it seem like a fairly tedious manual
process. Is there a less-painful and intensive way to truss
things up? Something to generate a simple D wrapper from a
python module?
-Wyatt
If you want to call python from D, you should be able to install
pyd with dub. Depending on your python setup, it should Just
Work. If python is set up weird (ubuntu), you will need to
generate some custom dub config and insert it in your dub.json.
look for generate_dub_config.py on github for the generation
part. or install pyd with pip and run python -m
pyd.generate_dub_config
after that, you should be good to go. some example usage off the
top of my head that probably doesn't compile:
py_init();
InterpContext context = new InterpContext();
context.pystmts(`
from mutagen.flac import FLAC
audio = FLAC("example.flac")
audio["title"] = "An example"
`);
auto audio = context.audio;
audio.pprint();
audio.save();
Re: Dlang seems like java now,but why not let d more like C# Style?
On Sunday, 15 March 2015 at 14:58:54 UTC, Idan Arye wrote: Even if we can't get the lambdas as syntax tress, the fact that we can send whatever types we want to the delegates and overload operators and stuff means we can still convert the lambdas into SQL. There are limitations on operator overloading that make it much less likely you can use the exact same lambdas for collections and sql. Bad for testability. At any rate, I really don't like what C# did with LINQ-to-SQL. The whole special-syntax to functional-style to syntax-tree to SQL is too overcomplicated - a simply lisp-style macro system(like what they have in Scala or Rust) could have done the trick in a simpler and faster way. overcomplicated? probably - it's microsoft. And any time I have to manipulate the ASTs I find myself wishing for a language with pattern matching. I wonder if F# offers anything in that regards..
Re: Dlang seems like java now,but why not let d more like C# Style?
On Saturday, 14 March 2015 at 23:57:33 UTC, weaselcat wrote: On Saturday, 14 March 2015 at 23:46:28 UTC, Ellery Newcomer wrote: And C# has LINQ, which when combined with the last point is fricken awesome. what does LINQ offer that UFCS-style functional programming does not? LINQ basically is a UFCS-style api. AST reflection is what makes it nice. consider: X.Where(x = x.Members.Count() == x.Admins.Count()) straightforward in both D and C# when X is an array or container type. When X is a table in a database, things get tricky for D. C# can interpret the lambda as an ExpressionFunc (an AST type), so the implementation of X can reflect over the body of the lambda and use it to generate the appropriate SQL. ORMs such as entity framework and nhibernate do this now.
Re: Dlang seems like java now,but why not let d more like C# Style?
On Saturday, 14 March 2015 at 13:52:13 UTC, Craig Dillabaugh wrote: I don't have any C# experience so I can't compare those languages much, but I've heard people say their are D / C# similarities. Anyway, this isn't a criticism of your comment, I was just curious what (other than the shared C++ syntax heritage) you find so Java-like in D? Cheers, Craig I've been using C# pretty extensively for the last year or so. Superficially, at least, C# and D are pretty similar, eg auto (var), foreach, lambdas, classes and structs. C# is more biased towards OO than D. Metaprogramming is significantly weaker in C#. This is probably the one area where I've wished for some of D's functionality. Reflection is all runtime. C# has some AST capabilities that D doesn't. This is probably the main area where I envy C# when using D. And C# has LINQ, which when combined with the last point is fricken awesome.
Re: embedding Pyd in Windows program
On Saturday, 14 March 2015 at 07:28:04 UTC, Matt wrote: Yeah, dub is what I'm using. Actually, I made a mistake regarding the py_eval. I'm including the pyd modules in a module other than the one that has my main() function, so they weren't visible. I feel like a proper idiot for that one.. So I set up a separate project to test the samples exactly. The simple_embedded sample seems to work no problem. I haven't gotten round to trying the shared_embedded, yet, but I will do at some point. Does pyd have any documentation, or are we working from the source for understanding the functions? there is readthedocs: http://pyd.readthedocs.org/en/latest/ there is [old] ddoc: http://ariovistus.bitbucket.org/index.html which I've been meaning to figure out how to get into readthedocs. there is a confluence space: https://pythond.atlassian.net/wiki/display/pyd/pyd+Home where I occasionally log tidbits that might be of value
Re: embedding Pyd in Windows program
On Friday, 13 March 2015 at 19:05:59 UTC, Matt wrote: example code, see if I can figure it out, but if you can advise, that would be fantastic. Thank you for all the help so far, it's really been appreciated My penitence for not putting this information on readthedocs. I've tried the hello.d example from GitHub, and get the error message: Error: template instance py_eval!string template 'py_eval' is not defined Unfortunately, that's all I seem to get. Is py_eval not deprecated in 0.9.4? hmm. that's odd. are you trying to build with dub? the only examples that build with dub are in examples/dub. the rest use distutils.
Re: embedding Pyd in Windows program
On Friday, 13 March 2015 at 09:38:45 UTC, Matt wrote:
I used the ~0.9.4 branch in dub, and I'm not sure how to
change configuration. Do you mean I should be using ~master
or ~develop?
nope. configurations are a different thing.
you can set them in your project's dub.json. example:
https://github.com/ariovistus/pyd/blob/master/examples/dub/simple_embedded/dub.json
for your project, I think you'd want
subConfigurations: {
pyd: python34,
}
as for the transferring the python3.dll, I downloaded and
installed a fresh copy of the latest Python build, version 3.4,
and copied the libraries from there. Even so, I had to add
PYD_PACKAGE_DIR manually to get it to work.
PYD_PACKAGE_DIR is necessary for linking the OMF files found in
infrastructure/windows. hmm. why did it not Just Work?
I'm not sure I'm going to be able to run the python snippet you
sent, since my program, which currently opens a window for
three seconds before closing again, doesn't even get that far,
and chokes when I run py_init().
you can put it in the top of site.py
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: PyD-like wrapping for Excel/VBA and Julia?
On 12/18/2014 12:41 PM, Laeeth Isharc wrote:
I have a bunch of D functions I would like to make available to Excel
(and possibly Julia) without having to write wrappers for each function
individually.
I've thought about refactoring the reflection parts of pyd into a
reusable library for e.g. resurrecting RuD. Come to think of it, that
would probably be necessary for supporting pypy.
It'd be a heck of a lot of work, though.
For your wrapper, you can probably do something like
extern(Windows) double vbwrap_test(double* inp,size_t num_inp,double*
oup,size_t num_oup)
{
return test(inp[0 .. num_inp], arg_oup[0 .. num_oup]);
}
with .dup sprinkled in as you see fit. And you don't need to explicitly
copy the results back! Might need to take the ref off oup in test..
Re: threading issues with D - C - Python
On 12/07/2014 03:12 PM, Michael wrote: now to figure out how to use them in the general case. This is great.. Thank you. I'm looking forward to being able to try the finished result. My build servers are broken at the moment, but I think I have this fixed, on linux at least.
Re: detaching a thread from druntime 2.067
On 12/16/2014 10:41 AM, Sean Kelly wrote: On Tuesday, 16 December 2014 at 04:56:10 UTC, Ellery Newcomer wrote: If I have a thread that I need to detach from druntime, I can call thread_detachInstance, but for 2.066, this function does not exist. Is there any way to do this in 2.066? I notice there is a thread_detachByAddr, but I'm not sure how to get a ThreadAddr out of a Thread.. thread_detachThis? the thread I want to detach isn't currently running.
detaching a thread from druntime 2.067
If I have a thread that I need to detach from druntime, I can call thread_detachInstance, but for 2.066, this function does not exist. Is there any way to do this in 2.066? I notice there is a thread_detachByAddr, but I'm not sure how to get a ThreadAddr out of a Thread..
Re: threading issues with D - C - Python
On 12/07/2014 03:12 PM, Michael wrote: On Saturday, 6 December 2014 at 00:40:49 UTC, Ellery Newcomer wrote: On 12/04/2014 10:55 PM, Ellery Newcomer wrote: I guess tomorrow I can try messing around with thread_attachThis, as the fullcollect happening in #2 might be screwing with python data. But you aren't really passing anything from python to d or vice versa, so I'm not sure why the gc would need to know about the python threads. by gum, thread_attachThis and thread_detachThis fix the issue! now to figure out how to use them in the general case. This is great.. Thank you. I'm looking forward to being able to try the finished result. It would be great if there were some convenient hook in python to stick these calls. Near as I can tell, there isn't. That leaves you with either explicitly calling attach and detach with an exposed api, or pyd obsessively checking whether the current thread is registered. Actually, I suppose with a thread local flag the latter wouldn't be too bad. Mind if I incorporate your example into pyd's test suite?
Re: threading issues with D - C - Python
On 12/04/2014 10:55 PM, Ellery Newcomer wrote: I guess tomorrow I can try messing around with thread_attachThis, as the fullcollect happening in #2 might be screwing with python data. But you aren't really passing anything from python to d or vice versa, so I'm not sure why the gc would need to know about the python threads. by gum, thread_attachThis and thread_detachThis fix the issue! now to figure out how to use them in the general case.
Re: threading issues with D - C - Python
On 12/04/2014 02:11 PM, Michael wrote: On Thursday, 4 December 2014 at 03:22:05 UTC, Ellery Newcomer wrote: dustmite? Not sure what went wrong with dustmite, but every time I tried it it just started deleting all the files in the directory and setup.py would give errors. I manually deleted a reasonable chunk of the code and I'm left with these files which still seem to cause segfaults: Main code: http://pastebin.com/zqgNTk9w PyD definitions: http://pastebin.com/6mRH3KZZ setup.py: http://pastebin.com/i9Ph78UC test code that causes segfaults: http://pastebin.com/1ukzShVh Cheers, Michael. hmm.. looks like here it originates in python when it tries to acquire the GIL. specifically, pthread_cond_timedwait is segfaulting. in your code, execution inside a python thread makes it to receiveTimeout in get_image. it made it past receiveTimeout in acquire. then I guess there is a context switch. the main python thread throws an exception, but a number of things trigger the segfault. I think it's just the interpreter loop calling RestoreThread. backtrace looks like #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 #1 0x003799d07bb3 in PyCOND_TIMEDWAIT (cond=0x379a063220 gil_cond, mut=0x379a0631e0 gil_mutex, us=5000) at /usr/src/debug/Python-3.3.2/Python/condvar.h:103 #2 take_gil (tstate=tstate@entry=0x604410) at /usr/src/debug/Python-3.3.2/Python/ceval_gil.h:224 #3 0x003799d081fb in PyEval_RestoreThread (tstate=tstate@entry=0x604410) ... It looks like this is the python main thread. I see two other threads. (i took out one of your python spawns) #2 looks to be your listener thread. std.concurrency.send seems to have gotten it into a gc_malloc, but it looks like it's just waiting. it's currently in sem_wait. this one would have been spawned in D code by #3 #3 is your other python thread. it is also in pthread_cond_timedwait. by its stack trace, receiveTimeout is just waiting. I guess tomorrow I can try messing around with thread_attachThis, as the fullcollect happening in #2 might be screwing with python data. But you aren't really passing anything from python to d or vice versa, so I'm not sure why the gc would need to know about the python threads. not exactly my area of expertise, this.
Re: threading issues with D - C - Python
On 12/03/2014 04:43 PM, Michael wrote: On Wednesday, 3 December 2014 at 21:35:48 UTC, ketmar via Digitalmars-d-learn wrote: ah, dsource strikes back! that vile site keep biting us again and again. let's hope that new admins will kill it for good. Yeah. I've got the new PyD and it compiles and does everything I want much nicer, but it appears to have the exact same problems. When calling a python thread to my code, it can cause segfaults and hanging issues. Cheers, Michael. okay. that's not too surprising. If you can get me a minimal example, I'd be happy to have a look since pyd should probably support this case.
Re: threading issues with D - C - Python
On 12/03/2014 06:56 PM, Michael wrote: On Thursday, 4 December 2014 at 02:31:51 UTC, Ellery Newcomer wrote: okay. that's not too surprising. If you can get me a minimal example, I'd be happy to have a look since pyd should probably support this case. Cool. Unfortunately most of the times I've attempted to reduce this down it always seems to work, but I think that's because I often did the example code in D. I'll play around with it and try to send you an example. Cheers, Michael. dustmite?
Re: threading issues with D - C - Python
On 12/02/2014 05:07 PM, Michael wrote: Hi. I'm new here and this is my first post. I'm not sure this is the right subforum for it, but wasn't sure where else to put it either. I've written a library to talk to some external hardware using a socket. It uses the std.concurrency threads to send messages between the main D-object for the hardware and the D-object for the sockets. I then wanted to be able to call these functions from Python. PyD appeared to be out of date, so I've been using a D - C interface, and a C - Python interface. The python code will often run from different python threads, so I then added yet another message-passing layer between the D-C interface and the D-hardware interface. are you looking at this pyd: https://bitbucket.org/ariovistus/pyd
Re: building shared library from D code to import into cython
On Sunday, 12 October 2014 at 16:07:19 UTC, Laeeth Isharc wrote: Any thoughts on speed in 2014 of pyd vs using cython to talk to D directly via C/C++ interface? I saw this old coment here: pyd is basically just a convenience layer on top of the C interface. The part that would most likely screw with performance would be conversion from D objects to python objects and vice versa since that normally does a value copy. At the time of that comment, pyd's strategy for arrays was just iterate and convert each element. Now pyd can take advantage of the buffer protocol if it is exposed (2.7+), so converting e.g. numpy arrays should be just a memcopy. If you want by ref semantics instead of by value, use PydObject instead of a D type in your function signature. You can also turn off all conveniences and just use the C api with raw_only (https://bitbucket.org/ariovistus/pyd/wiki/CeleriD)
Re: building shared library from D code to import into cython
On Wednesday, 8 October 2014 at 00:25:57 UTC, Laeeth Isharc wrote: Hi. Thanks for the quick response. The -defaultlib was left around from trying all kinds of combinations of dmd and gcc. I am not used to gcc, and it will take me some time to become properly acquainted with all the options. I managed to get it to compile with default dmd rpm: https://github.com/ariovistus/cythonic_d fedora 20, x86_64 Are you aware of pyd? (https://bitbucket.org/ariovistus/pyd) It knows how to build shared libraries, so I recommend you play with it, if only to watch how it does that. Biggest gotcha is starting up druntime.
how to tell if a thing is a template
Can't think off the top of my head how you do this
template IsTemplate(alias t) {
??
}
static assert(IsTemplate!IsTemplate)
Re: Something like Python's psutils for D?
On Saturday, 12 July 2014 at 08:34:41 UTC, Thomas Mader wrote: The Subject says it all, is something like psutils available in D? would psutils itself be acceptable? https://bitbucket.org/ariovistus/pyd
Re: C++'s defaulted comparison operators proposal
On Wednesday, 18 June 2014 at 05:49:30 UTC, Ali Çehreli wrote: Can you come up with a D library solution to the following C++11 proposal: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3950.html did this years ago (or something similar, at least): https://bitbucket.org/ariovistus/multi_index/src/0993f8604c1438f6d9f26f580939b42fdd159a67/src/multi_index.d?at=default#cl-4654 example: https://bitbucket.org/ariovistus/multi_index/src/0993f8604c1438f6d9f26f580939b42fdd159a67/unittests/multi_compare.d?at=default
Re: Linking with C on Windows
On Thursday, 5 June 2014 at 23:12:56 UTC, Mark Isaacson wrote: I need to eventually be able to export a dll that can talk with anything. how would using dmc conflict with this goal? dmd/dmc output omf object files, windows infrastructure is all coff object files. linux/mingw/etc are.. something else.. your options are 1. use dmd/dmc, and if you need to link to windows api dlls or others, use coffimplib (here - ftp://ftp.dlang.org/) to convert the appropriate lib files. 2. if you can stomach the loss of generality, use dmd -m64, which does output coff object files and go your merry way with vc++. (I don't do this, so don't quote me on this) 3. use the mingw builds of ldc/gcc (I don't do this either and can't comment on how much fun you'll have getting dlls out of them/linking to other dlls)
Re: Using D static library from C
On Thursday, 5 June 2014 at 18:51:25 UTC, George Sapkin wrote: I'm trying to link a simple D static library to C code, but I'm can't figure out how to do it properly without getting a segfault when running it. try this: dmd -lib test.d -defaultlib=libphobos2.a -oflibtest.a gcc main.c libtest.a -l:libphobos2.a -lpthread -lm -lrt
Re: Using D static library from C
On Friday, 6 June 2014 at 02:17:50 UTC, George Sapkin wrote: On Friday, 6 June 2014 at 02:13:08 UTC, Ellery Newcomer wrote: On Thursday, 5 June 2014 at 18:51:25 UTC, George Sapkin wrote: I'm trying to link a simple D static library to C code, but I'm can't figure out how to do it properly without getting a segfault when running it. try this: dmd -lib test.d -defaultlib=libphobos2.a -oflibtest.a gcc main.c libtest.a -l:libphobos2.a -lpthread -lm -lrt Awesome! That works! Thanks. So is dmd linking to shared/different phobos2 by default or something? yeah, -defaultlib=libphobos2.so is the other option, I guess it's default now.
Re: dxl (the d port of jexcelapi)
On Thursday, 8 May 2014 at 20:57:08 UTC, Taylor Hillegeist wrote: So i was thinking i wonder if anyone has a d library for excel and behold there it was. however, it seems like d has grown since this was written. I'm getting bunches of errors telling me that i can't override a function without the override keyword. which is not a big deal, however I seem to be missing libraries. std.date; cannot be found :( is this equivalent to std.datetime? dcollections.LinkList; I found it but should i use It? is there not something in std.containers; that would replace it? Last I used std.containers (which admittedly has been a few years), I developed a pretty deep distrust of DList. Personally, I would use multi_index, but you are probably better off sticking with dcollections. unless steve hasn't been maintaining it.. Also, I'm the author/porter of dxl. I think I quit maintaining it because I was waiting for the new io api, which I guess still hasn't happened. I don't really have time to work on it right now, but if you have questions, feel free to ask.
string - string literal
is there a function in phobos anywhere that takes a string and escapes it into a string literal suitable for string mixins? something like assert (f(abc\ndef) == \abc\\ndef\);
