Re: Dart bindings for D?
On Thursday, 30 October 2014 at 02:27:58 UTC, ketmar via Digitalmars-d-learn wrote: it was very funny to show some people D code with your jsvar and listenting how they don't want to learn just another scripting language. and then compile the code with DMD to confuse them even more. hehe, that was the main idea!
Not able to compile that code
Hi, Im trying to compile this code but I have a Segmentation Fault. http://dpaste.dzfl.pl/882618dc09f1 It's coming from the template. I'm probably doing something bad. Is this a bug ?
Re: Not able to compile that code
On 10/31/14 10:51 AM, Misu wrote: Hi, Im trying to compile this code but I have a Segmentation Fault. http://dpaste.dzfl.pl/882618dc09f1 It's coming from the template. I'm probably doing something bad. Is this a bug ? Yes. Any time the compiler has a segmentation fault, it's a bug. Please file here and tag with ice https://issues.dlang.org/enter_bug.cgi Thanks -Steve
Re: Not able to compile that code
On Friday, 31 October 2014 at 14:59:11 UTC, Steven Schveighoffer wrote: Yes. Any time the compiler has a segmentation fault, it's a bug. Please file here and tag with ice https://issues.dlang.org/enter_bug.cgi Thanks -Steve Ok done. Thank you.
Re: Dart bindings for D?
On Thursday, 30 October 2014 at 17:39:14 UTC, Laeeth Isharc wrote: Dart web server talk to a D analytics server via a socket. And 2) I cannot say that I definitely do not want to cache things and do some work on client, and so I need to see what's possible to avoid getting trapped in purely local optimum. One thing you should consider is that asm.js has this very cool ability to run eval() dynamically on the client and generate machinecode on the fly. You will probably get 30-50% of the D speed, but you will be getting OpenCL on the client in the future which will beat anything on the CPU… Just sayin'. There's some cool JIT capabilities in browsers that can be used for optimized queries on data in combination with local storage (all modern web browsers support this). And it is only getting better… (But dart is still a safe bet… you can call out to Javascript)
win64 - win32.oaidl.VARIANT - error LNK2019
// bindings from
https://github.com/CS-svnmirror/dsource-bindings-win32/blob/308739a417eaaba85a5d3ce7741fd43d3042efe0/oaidl.d
---
import win32.oaidl;
// The following gives linker error: error LNK2019: unresolved
external
// symbol _D5win325oaidl7VARIANT6__initZ referenced
// in function ...
VARIANT v;
v.vt = VARENUM.VT_I4;
v.lVal = 1;
// while this works - no linker error
VARIANT v = { vt: VARENUM.VT_I4, lVal: 1 };
Defining a similar structure as VARIANT with anonymous structs
and unions targeting linux seemed to work fine without linker
problems. What is the idiomatic way of handling this on win64?
Re: win64 - win32.oaidl.VARIANT - error LNK2019
On Friday, 31 October 2014 at 15:56:54 UTC, deed wrote:
// bindings from
https://github.com/CS-svnmirror/dsource-bindings-win32/blob/308739a417eaaba85a5d3ce7741fd43d3042efe0/oaidl.d
---
import win32.oaidl;
// The following gives linker error: error LNK2019: unresolved
external
// symbol _D5win325oaidl7VARIANT6__initZ referenced
// in function ...
VARIANT v;
v.vt = VARENUM.VT_I4;
v.lVal = 1;
// while this works - no linker error
VARIANT v = { vt: VARENUM.VT_I4, lVal: 1 };
Defining a similar structure as VARIANT with anonymous structs
and unions targeting linux seemed to work fine without linker
problems. What is the idiomatic way of handling this on win64?
Your link is failing because the .init value of the struct is not
found. The .init will be in the object file corresponding to the
module where the struct is defined, so to fix the linker error,
add the win32.oaidl module to the list of modules you're
compiling and linking. An easy way to do that is to use rdmd
instead of dmd to build your program.
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
Re: win64 - win32.oaidl.VARIANT - error LNK2019
Your link is failing because the .init value of the struct is not found. The .init will be in the object file corresponding to the module where the struct is defined, so to fix the linker error, add the win32.oaidl module to the list of modules you're compiling and linking. An easy way to do that is to use rdmd instead of dmd to build your program. Thank you for your prompt reply and maintaining the bindings on GitHub! I used dub (with dmd). The win32 files reside in another directory and the path is specified in importPaths. If I understand you correctly, the oaidl.d file should also be specified in sourceFiles in the .json file?
shallow copy of const(Object)[]
I have a const(Object)[] and I want a shallow copy of the array.
.dup doesn't do it, which I thought a bug, but according to
Martin Nowak it's by design [1].
std.array.array fails, too. Is there really nothing in phobos for
this?
static import std.array;
void main()
{
const(Object)[] a;
version(dup) auto b = a.dup;
/* Nope. Apparently, dup is supposed to convert the elements
to mutable [1],
which doesn't work with const(Object), of course. */
version(array) auto c = std.array.array(a);
/* Nope. Tries to convert to mutable, too? */
version(meh)
{
typeof(a) d;
d.reserve(a.length);
foreach(e; a) d ~= e;
}
}
[1]
https://github.com/D-Programming-Language/druntime/pull/1001#discussion_r19674927
Re: D support on SPARC/Solaris
On Friday, 31 October 2014 at 16:10:01 UTC, Wyatt wrote: On Thursday, 30 October 2014 at 15:39:55 UTC, Joakim wrote: 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? None that I know of, look at the commit log and grep the source for powerpc.
Re: Multiple declarations in a C++ namespace
On 10/31/2014 12:55 AM, Meta wrote:
On Friday, 31 October 2014 at 02:01:00 UTC, Paul O'Neil wrote:
I'm trying to bind to some C++ code, but when I compile the D side,
there are errors. Here's my reduced test case:
// C++
namespace ns {
void func1();
void func2();
}
// D
module cpp;
extern(C++, ns) void func1();
extern(C++, ns) void func2()
dmd says:cpp_test.d(4): Error: namespace cpp.ns conflicts with namespace
cpp.ns at cpp_test.d(3)
What does this mean and how do I fix it?
Thanks!
Did you try this?
extern(C++, ns)
{
void func1();
void func2();
}
The compiler probably thinks you're trying to declare two separate
namespaces. I'm not sure if this is intended or not.
Thanks for the response. That does work.
Should I file a bug report or create a PR for the docs?
--
Paul O'Neil
Github / IRC: todayman
Re: shallow copy of const(Object)[]
On Friday, 31 October 2014 at 18:39:00 UTC, anonymous wrote:
I have a const(Object)[] and I want a shallow copy of the array.
.dup doesn't do it, which I thought a bug, but according to
Martin Nowak it's by design [1].
std.array.array fails, too. Is there really nothing in phobos
for
this?
static import std.array;
void main()
{
const(Object)[] a;
version(dup) auto b = a.dup;
/* Nope. Apparently, dup is supposed to convert the
elements
to mutable [1],
which doesn't work with const(Object), of course. */
version(array) auto c = std.array.array(a);
/* Nope. Tries to convert to mutable, too? */
version(meh)
{
typeof(a) d;
d.reserve(a.length);
foreach(e; a) d ~= e;
}
}
[1]
https://github.com/D-Programming-Language/druntime/pull/1001#discussion_r19674927
In a such setup I'd rather define b as a pointer to the const
array a, after all if a is const, a pointer to a would be
safe ? I mean its adress wont change. I also meant that if the
content doent change (const) there is no need to copy.
But that's a workaround, It's all about what const(type) mean
here.
My two kopeks...
string, char[], overloaded functions.
Ok, void Foo(string name, string value); void Foo(string name, int value); then... char[] buf = woo.dup; Foo(bar,woohoo); // works ok Foo(bar,buf~hoo); // fails, error says cant match params (string, int) So shouldnt char[] implicity convert to string, and hence match the (string,string) parameter list? is there a better way than doing... cast(string)(buf~hoo) to get it to pick the correct overload?
Re: shallow copy of const(Object)[]
On Friday, October 31, 2014 18:38:59 anonymous via Digitalmars-d-learn wrote:
I have a const(Object)[] and I want a shallow copy of the array.
.dup doesn't do it, which I thought a bug, but according to
Martin Nowak it's by design [1].
std.array.array fails, too. Is there really nothing in phobos for
this?
static import std.array;
void main()
{
const(Object)[] a;
version(dup) auto b = a.dup;
/* Nope. Apparently, dup is supposed to convert the elements
to mutable [1],
which doesn't work with const(Object), of course. */
version(array) auto c = std.array.array(a);
/* Nope. Tries to convert to mutable, too? */
version(meh)
{
typeof(a) d;
d.reserve(a.length);
foreach(e; a) d ~= e;
}
}
[1]
https://github.com/D-Programming-Language/druntime/pull/1001#discussion_r196
74927
So, by shallow copy, you mean that you want an array that contains the same
elements but is a new array? If that's what you want, just slice the array.
auto b = a[];
Sure, they'll point to the same spot in memory still, but because all of the
elements are const, you can't mutate them, so it really doesn't matter. All it
affects is that because both arrays have the same block of memory after them,
appending to one of them would make it so that appending to the other would
force it to reallocate. For for most intents and purposes, you essentially
have two different arrays.
As for std.array.array, I suspect that the problem is that it's using emplace
internally, and that isn't playing well with const. Certainly, that's what the
second error message that you get when you try looks like
/usr/include/D/phobos/std/conv.d(3844): Error: template instance
std.conv.emplaceImpl!(const(Object)).emplaceImpl!(const(Object)) error
instantiating
I'd have to dig into it further to see why though. But if you absolutely must
have the two arrays referring to separate blocks of memory (though I don't see
why you would), then you could always just build a new array yourself by doing
something like
const(Object)[] a;
const(Object)[] b;
b.reserve(a.length);
foreach(e; a)
b ~= e;
You should probably create a bug report for std.array.array though, since it
arguably should work. At minimum, it could do something like that code sample,
though that's obviously not ideal in comparison to doing something like using
emplace. I'm not sure what the restrictions on emplace with regards to const
and immutable are though. Certainly, it's harder to support them, since you
can't overwrite const or immutable elements in an array.
- Jonathan M Davis
Re: string, char[], overloaded functions.
On Friday, 31 October 2014 at 23:59:54 UTC, dajones wrote: So shouldnt char[] implicity convert to string Nope, char[] casting to string is generally a bad thing that should be avoided because it can leave you with a mutable string, which isn't supposed to happen. In your case, why are you using char[] for the buf instead of just string? BTW one could argue that char[] ~ operator should yield something that's implicitly convertable, since it allocates a new memory block anyway, but that's not how it works right now.
Re: string, char[], overloaded functions.
On Friday, October 31, 2014 23:58:43 dajones via Digitalmars-d-learn wrote: Ok, void Foo(string name, string value); void Foo(string name, int value); then... char[] buf = woo.dup; Foo(bar,woohoo); // works ok Foo(bar,buf~hoo); // fails, error says cant match params (string, int) So shouldnt char[] implicity convert to string, and hence match the (string,string) parameter list? is there a better way than doing... cast(string)(buf~hoo) to get it to pick the correct overload? How could char[] implicitly convert to string? string is immutable(char)[], so its elements can't be changed, whereas char[]'s can be. So, if char[] implicitly converted to immutable(char)[], either it would be by casting and make it possible to violate the immutability of the characters (because something could change the original char[] array, and then affect the supposedly immutable characters in the one that came from the cast), or it would be doing idup for you, which would then be an invisible allocation and potential performance hit. string and char[] will implicitly convert to const(char)[], but mutable types don't generally implicitly convert to immutable ones, immutable ones don't implicitly convert to mutable ones, and const doesn't implicitly convert to either. The reason that woohoo works is because string literals are strings, not char[]. In the case of, buf ~ hoo, it generates a new char[] with the elements of buf and hoo, because buf was char[], not string, and char[] isn't implicitly convertible to either string or int. If you want a function to take any type of mutability for strings, then you can use const: void foo(const(char)[] name const(char)[] value); though that has the downside of making it so that you're stuff using const, which is particularly annoying if the function returns const(char)[] foo(const(char)[] name const(char)[] value); To fix that, you can use inout inout(char)[] foo(inout(char)[] name inout(char)[] value); so that the constness stays the same, but then the constness would have to match in this case, because there are two inout parameters. If you want to accept any constness without dealing with inout and without having to use const, then you can just templatize the function, e.g. C[] foo(C, D)(C[] name, D[] value) if(is(C == char) is(D == char)) and to accept any character type, you could do something like C[] foo(C, D)(C[] name, D[] value) if(isSomeChar!C isSomeChar!D) but obviously that gets more complicated. In any case, the only type of argument that will be accepted for a string parameter is string, not char[] or const(char)[], and casting to string from char[] will violate the type system if any other references to that same array exist (making it possible for the supposedly immutable chars to be mutated). So, you should use either idup or to!string() (the advantage of std.conv.to being that if the argument ever changed to string, no copy would be made, whereas idup would still make a copy). - Jonathan M Davis
Re: Multiple declarations in a C++ namespace
On Fri, 31 Oct 2014 19:23:06 -0400 Paul O'Neil via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Thanks for the response. That does work. Should I file a bug report or create a PR for the docs? i think it will be fine. and i think that this is more like a bug, 'cause it's ovbious that user wants the same namespace, not two identically named ones. signature.asc Description: PGP signature
Re: Multiple declarations in a C++ namespace
On Friday, 31 October 2014 at 23:22:50 UTC, Paul O'Neil wrote: Thanks for the response. That does work. Should I file a bug report or create a PR for the docs? It might be a good idea to create a thread in DigitalMars.D to get clarification on the intended behaviour. A doc PR never hurts either.
Re: string, char[], overloaded functions.
On Sat, 01 Nov 2014 00:05:19 + Adam D. Ruppe via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: BTW one could argue that char[] ~ operator should yield something that's implicitly convertable, since it allocates a new memory block anyway, but that's not how it works right now. it's not necessarily allocates. but `(buf~hoo).idup` does, so it can be used. ;-) signature.asc Description: PGP signature
