Re: Calling python code from D
On Thursday, 25 February 2016 at 22:28:52 UTC, jmh530 wrote: I think PyD is really your best option. That's what I figured, but I wanted to be sure because, well... http://pyd.readthedocs.org/en/latest/embed.html ...these are some sparse docs. I did stumble into them, but it feels like a bit of a work-in-progress or second-class citizen, so I was kind of hoping someone else had taken the torch and run with it. Maybe I'll have to shave a yak. :/ -Wyatt
Calling python code from D
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
Re: why mkdir can't create tree of dirs?
On Tuesday, 9 February 2016 at 20:20:59 UTC, Suliman wrote: It's look like that I can only create one nesting level sub folder, for example there is exists dir: D:\foo I can't create dir D:\foo\bar\baz I can only create D:\foo\bar http://dlang.org/phobos/std_file.html#.mkdirRecurse -Wyatt
Re: How do you reference variables in an AA of Variants?
On Tuesday, 9 February 2016 at 03:49:11 UTC, Enjoys Math wrote: This: double b = 1.0; Variant[string] aa = ["b": &b]; writeln(aa["b"]); fails with: Error: cannot implicitly convert expression(["b":&b]) of type double*[string] to VariantN!20u[string] Helps please! I've found bugbears like this are distressingly common in std.variant. Another one you might find yourself dealing with is https://issues.dlang.org/show_bug.cgi?id=10223, which applies to AAs as much as regular arrays. It's actually why I stopped using it in favour of Adam Ruppe's arsd.jsvar. -Wyatt
Re: Things that keep D from evolving?
On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote: I see... By any chance, can we solve this issue with GC managed pointers? Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen. You asked about things that prevent improvement, right? Here's the big one, and a major point of friction in the community: Walter and Andrei refuse to break existing code in pursuit of changes that substantially improve the language. (Never mind that code tends to break anyway.) -Wyatt
Re: D support on SPARC/Solaris
On Thursday, 30 October 2014 at 15:39:55 UTC, Joakim wrote: Someone may have been thorough when adding arches to certain files, but that in no way implies much actual support. Looking closer, it's all ELF header stuff, so that sounds about right. You may be able to combine the existing Solaris support and the sparc backend of llvm or gcc and get pretty far. A lot of the work should just be translating headers needed for the solaris/sparc sections in druntime. You could look at the linux/powerpc work Kai did with ldc for an idea of the changes necessary for a new arch. Sounds fairly reasonable to me. Happen to have a link to a commit or branch with that or do I need to go digging? As kagamin said, dmd's backend is i386/x86_64 only, so you have to use ldc or gdc. Never really made that connection (because lol PCs), but it makes sense when I think about it. Point was more that I don't care even if I have to compile to C and then build _that_. Thanks for the response. If it looks like there's a tenable path, then comes the hard part: getting my boss on board with this. orz -Wyatt
D support on SPARC/Solaris
At work, I have to target SPARC/Solaris. I'm writing code to interface with an internal network protocol, so my current choices are C and (old) C++ (remember Sun Studio? I wish I didn't have to). Having looked, it seems like there's some manner of support for SPARC in the runtime, but restricted to Linux and FreeBSD? Is that correct? In which case, what would an enterprising individual have to actually do (read: fix or implement) to use D in that environment? (If it comes down to it, it may be worth my while to add it myself.) This echoes a thread Nordlöw started about six months ago, but my constraints aren't as rigid: DMD would be fine for me. I just pine for non-crap language. -Wyatt
Re: Nesting Variants
On Monday, 20 May 2013 at 08:55:24 UTC, evilrat wrote: yes, you forgot to take exact value, it doesn't know anything about array you put it in, so if you take that array explicitly and put value on array element it would work ender[0] = one; ender[0].get!(Variant[])[0] = key; writeln(ender[0][0]); // writes 1 also you can check whats inside by doing just this "writeln(ender);" in case you are not sure what's going on. I was trying to do this as a way to obtain a concise syntax for manipulating a tree of elements deserialized at runtime, ex: data["foo"]["bar"] = "baz"; assert( data["foo"]["bar"] == "baz" ); foreach( subtree; data["foo"] ) doSubtreeOp( subtree ); Having to place .get!(Variant[]) between each dereference will defeat my use case. Associative arrays fail in the same way, btw. I'm using integers in the first example because it should be simpler to get those right. I expected this to work because the value of 'ender[0]' will be a variant that contains an array, and such a variant should be able to index the contained array because of its opIndex overload.
Nesting Variants
I'm trying to use Variants and ran into the following sort of
situation:
//Using DMD 2.062
import std.stdio;
import std.variant;
void main(){
int key = 1;
Variant[] one;
Variant[] ender;
one = new Variant[](1);
ender = new Variant[](1);
//This bails:
//std.variant.VariantException@std/variant.d(1224): Variant:
attempting to use incompatible types int and
std.variant.VariantN!(32LU).VariantN
ender[0] = one;
ender[0][0] = key;
writeln(ender[0][0]);
//Also bails only rather than int, it's
std.variant.VariantN!(32LU).VariantN*:
//ender[0][0] = new Variant(key);
//This works fine:
//one[0] = key;
//ender[0] = one;
//writeln(ender[0][0]);
}
The long and short of it seems to be that you can't (easily)
assign to an element of a Variant array within a Variant array
but you CAN access it as long as you build the whole thing
upside-down. Can anyone shed some light on why this is? Am I
just missing some not-completely-obvious step?
Oh, I should probably mention I was originally using associative
arrays, so I thought maybe I'd hit one of the bugs related to
that. But as you can see, it's happening even with ordinary
arrays.
