Porting from D1 to D2
I have a program that is almost ported from D1 to D2 but there is still a problem with a reference to object.Throwable.toString(scope void delegate(in string) sink); With OPTLINK (32-bit): Error 42: Symbol Undefined _D6object9Throwable8toStringMxFMDFxAyaZvZv (const(void function(scope void delegate(const(immutable(char)[] object.Throwable.toString) With link.exe (64-bit): vibrant_derelict.lib(exception_311_6db.obj) : error LNK2001: unresolved external symbol _D6object9Throwable8toStringMxFMDFxAyaZvZv vibrant_derelict.lib(exception_314_c30.obj) : error LNK2001: unresolved external symbol _D6object9Throwable8toStringMxFMDFxAyaZvZv vibrant_derelict.lib(exception_312_89d.obj) : error LNK2001: unresolved external symbol _D6object9Throwable8toStringMxFMDFxAyaZvZv vibrant_common2.lib(error_a0_4d3.obj) : error LNK2001: unresolved external symbo l _D6object9Throwable8toStringMxFMDFxAyaZvZv vibrant_common2.lib(error_9e_2e1.obj) : error LNK2001: unresolved external symbo l _D6object9Throwable8toStringMxFMDFxAyaZvZv vibrant_common2.lib(error_9f_461.obj) : error LNK2001: unresolved external symbo l _D6object9Throwable8toStringMxFMDFxAyaZvZv vibrant_derelict.lib(exception_313_a31.obj) : error LNK2001: unresolved external symbol _D6object9Throwable8toStringMxFMDFxAyaZvZv vibrant.obj : error LNK2001: unresolved external symbol _D6object9Throwable8toSt ringMxFMDFxAyaZvZv vibrant_common2.lib(state_eb9_2ed.obj) : error LNK2001: unresolved external symb ol _D6object9Throwable8toStringMxFMDFxAyaZvZv vibrant_common2.lib(error_9d_42f.obj) : error LNK2001: unresolved external symbo l _D6object9Throwable8toStringMxFMDFxAyaZvZv vibrant_common2.lib(error_a1_398.obj) : error LNK2001: unresolved external symbo l _D6object9Throwable8toStringMxFMDFxAyaZvZv .dub\build\application-debug-windows-x86_64-dmd_2067-A5A845EF2ABB6AC157FC78217DE 83EB9\vibrant.exe : fatal error LNK1120: 1 unresolved externals I don't quite get what code could be generating that reference, since I don't call format or toString on a Throwable. Anyone has experience with this?
Re: std.concurrent Tid vector initialization problem
On Sunday, 28 June 2015 at 01:02:02 UTC, Charles Hixson wrote:
I'm planning an application where a series of threads each need
to be aware of the Tids of all the others. The number won't be
known at compile time, but that doesn't seem to change the
design.
All I've been able to come up with is a pair of loops, one to
spawn the threads, and collect their Tids, and a second for
each one to send its Tid to all the others. receive doesn't
seem to want to work with shared Tids. My original design was
to have a file level shared array of Tids, but receive (or
possibly send) objected to attempts to use them. They aren't
known until they've been spawned, so I can't pass them as spawn
parameters. Etc.
This seems like a very clumsy initialization design. Does
anyone have a better idea?
(The rough estimate of the number of Tids is six, but that's
likely to change from run to run.)
The most elegant solution I can think of is this:
struct Go { }
__gshared const Tid[] allTids;
void myfunc(...) {
receiveOnly!Go();
// do the work
}
shared static this() {
Tid[] tids;
foreach(thread; threads)
tids ~= spawn(myfunc, ...);
*cast(const(int)[]*) allTids = tids;
foreach(tid; allTids)
tid.send(Go());
}
I believe the cast is not even undefined behaviour, because it's
not immutable, but I'm not sure. But the const-ness guards
against accidental modification of `allTids` by a thread.
Alternatively, you could make `allTids` private, provide a public
getter, and implement the threads in another module.
Or you could simply leave the global array mutable and be careful
not to modify it.
Re: how to iterate on Array?
On Saturday, 27 June 2015 at 17:43:13 UTC, aki wrote:
But when I compile it by DMD 2.062 on Windows
it says:
testArray.d(5): Error: cannot infer argument types
(line 5 is at foreach(i, v; a[]) { )
2.062 is really ancient, we're about to release 2.068 soon.
Consider upgrading, because there have been tons of bugfixes
since your version.
On current DMD, the error message is slightly clearer:
Error: cannot infer argument types, expected 1 argument, not 2
Re: Pure delegate not quite pure?
On Sunday, 28 June 2015 at 09:19:16 UTC, Tofu Ninja wrote:
module main;
import std.stdio;
void main(string[] args)
{
auto d = foo();
writeln(d()); // prints 25
}
auto foo()
{
int x = 4;
pure int delegate() d = delegate()
{
return x*x;
};
writeln(d()); // prints 16
x = 5;
writeln(d()); // prints 25
return d;
}
I can see that after foo returns, then d will truly be pure as
x will no longer be modifiable, but just before that, it seems
d is not actually pure. Is this the intended behavior?
Here's a similar example where it's a bit clearer what's going on:
struct S
{
int x = 0;
int d() pure {return ++this.x;}
}
void main()
{
S s;
int delegate() pure d = s.d;
import std.stdio;
writeln(d()); /* prints 1 */
writeln(d()); /* prints 2 */
writeln(d()); /* prints 3 */
}
`d` isn't all that pure, right? You're seeing the concept of
weak purity in action. In D, the attribute `pure` really just
means doesn't access global mutable state. The function is
still allowed to mutate any arguments it gets, including hidden
ones. Here the method `d` has a hidden `this` parameter, and it
can mutate data through it. With a nested function, the enclosing
context is passed via a hidden parameter.
Properly/mathematically/strongly pure functions have additional
requirements on top of being marked `pure`. Read more here:
http://klickverbot.at/blog/2012/05/purity-in-d/
Re: how to string → uint* ?
On 6/28/2015 7:08 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: In addition to what anonymous said, you might want to raise a bug report with Derelict, because the function signatures are arguable wrong, though that depends on whether Derelict wants to provide a strict one-to-one mapping of the C code, or one that is already somewhat adapted to D: https://github.com/DerelictOrg/DerelictSFML2/blob/master/source/derelict/sfml2/graphics.d#L521-L522 alias da_sfText_setString = void function( sfText*,const( char )* ); The documentation says that this is for ANSI strings, but `char` in D is defined to be a *UTF8* code unit. Instead, the type should be `const(ubyte)*`. I've been mapping D char to C char in Derelict packages for 11 years. It's also what's recommended on the page about interfacing to C[1]. Although I do understand your point, I'm curious if anyone is actually taking the ubyte approach these days? Or has anyone actually encountered a problem with the char-char mapping? alias da_sfText_setUnicodeString = void function( sfText*,const( sfUint32 )* ); Probably better to use `const(dchar)*` here. Agreed. That's what I've been doing in recent additions. [1] http://dlang.org/interfaceToC.html
Re: Replacement of std.stream
On Sunday, 28 June 2015 at 05:04:48 UTC, DlangLearner wrote: I will convert a Java program into D. The original Java code is based on the class RandomeAccessFile which essentially defines a set of methods for read/write Int/Long/Float/String etc. The module std.stream seems to be a good fit for this job, but in its documentation, it is marked deprecated. So I'd like to know what is the replacement for this module. If I don't use this module, what is the other apporach I should use. Thanks for help. You can use std.stream. There is no candidate to replace it. Even if tomorrow someone comes with one, it has to be reviewed, accepted in std.experimental and after a while it would totally replace the old one. I think it's safe to say that std.stream will exist for at least 2 years in its current shape.
Bug or feature?
I don't see any reason why it should not compile.
import std.array;
import std.range;
import std.algorithm;
class Foo {
}
void main() {
auto result = iota(3).map!(i = new immutable Foo).array();
}
/usr/include/dmd/phobos/std/conv.d(4028): Error: cannot
implicitly convert expression (arg) of type immutable(Foo) to
test.Foo
/usr/include/dmd/phobos/std/conv.d(3931): Error: template
instance
std.conv.emplaceImpl!(immutable(Foo)).emplaceImpl!(immutable(Foo)) error instantiating
/usr/include/dmd/phobos/std/array.d(115):instantiated
from here: emplaceRef!(immutable(Foo), Foo, immutable(Foo))
test.d(9):instantiated from here:
array!(MapResult!(__lambda1, Result))
Pure delegate not quite pure?
module main;
import std.stdio;
void main(string[] args)
{
auto d = foo();
writeln(d()); // prints 25
}
auto foo()
{
int x = 4;
pure int delegate() d = delegate()
{
return x*x;
};
writeln(d()); // prints 16
x = 5;
writeln(d()); // prints 25
return d;
}
I can see that after foo returns, then d will truly be pure as x
will no longer be modifiable, but just before that, it seems d is
not actually pure. Is this the intended behavior?
Re: how to string → uint* ?
On Sunday, 28 June 2015 at 01:57:46 UTC, xky wrote: hello. :-) when i was using DerelictSFML2( http://code.dlang.org/packages/derelict-sfml2 ), i got this problem. CSFML doc had 'setUnicodeString': CSFML_GRAPHICS_API void sfText_setUnicodeString ( sfText * text, const sfUint32 * string ) *'sfUint32' same 'unsigned int'. how to convert string → uint? i just try that, but not work. string test = 안녕, こんにちは; string* test_p = test; sfUint32* uintObject = cast(sfUint32*)test_p; sfText_setUnicodeString( , uintObject ); thanks, :) Don't try casting just because you guess it could maybe work. The best documentation for setUnicodeString I could find is this: https://github.com/SFML/CSFML/blob/master/include/SFML/Graphics/Text.h#L243 which is pretty bad. It doesn't say if unicode is UTF8/16/32. `sfUint32` hints at UTF32, so I'll go with that. A D `string` is in UTF8, so you'll have to convert it to a `dstring` which is in UTF32 (UTF16 would be `wstring`). You can use std.conv.to for that: string test = 안녕, こんにちは; dstring test32 = test.to!dstring; Alternatively, you can simply make `test` a dstring from the start: dstring test = 안녕, こんにちは; The documentation also doesn't say if the string has to be null-terminated. Since the function doesn't take a length, I'm assuming that it has to be. D strings (of all varieties) are generally not null-terminated. String literals are, though. So if you're passing a hard-coded string, you're fine. But if the string is user input or otherwise generated at run time, you have to add a null character at the end. There's std.string.toStringz for that, but I'm afraid it's for UTF8 only. So you'd have to go into the details yourself. I'm continuing with `test` as above, which is null-terminated, because it's from a literal. Alright, the data is properly set up (hopefully). Now we need to get a `const sfUint32*` out of the `dstring`. I'm assuming `sfUint32` is just an alias for `uint`. So we need a `const uint*`. By convention, when a function takes a pointer and says it's a string, the pointer points to the first character of the string. `dstring` is an alias for `immutable(dchar)[]`, i.e. a dynamic array of `immutable dchar`s. Dynamic arrays have the `.ptr` property which is a pointer to the first element; exactly what we need. `test.ptr` is an `immutable(dchar)*` though, not a `const uint*`. `dchar` and `uint` have the same size. And any bit-pattern is valid for a `uint`, so `dchar`s can be reinterpreted as `uints` without problem. There's std.string.representation which does just that. Combining `representation` with `.ptr` you get an `immutable(uint)*` which implicitly converts to `const uint*`: dstring test = 안녕, こんにちは; sfText_setUnicodeString( , test.representation.ptr); That's it. Another gripe about the documentation, though: It also doesn't say if the pointer has to be persistent or not. The string data may be garbage collected once it goes out of scope, so I'm betting on the pointer not having to be persistent, here.
Re: how to string → uint* ?
In addition to what anonymous said, you might want to raise a bug report with Derelict, because the function signatures are arguable wrong, though that depends on whether Derelict wants to provide a strict one-to-one mapping of the C code, or one that is already somewhat adapted to D: https://github.com/DerelictOrg/DerelictSFML2/blob/master/source/derelict/sfml2/graphics.d#L521-L522 alias da_sfText_setString = void function( sfText*,const( char )* ); The documentation says that this is for ANSI strings, but `char` in D is defined to be a *UTF8* code unit. Instead, the type should be `const(ubyte)*`. alias da_sfText_setUnicodeString = void function( sfText*,const( sfUint32 )* ); Probably better to use `const(dchar)*` here.
Re: kill and thisProcessID
On Wednesday, 24 June 2015 at 11:58:37 UTC, Nordlöw wrote: I believe the best solution is to add a new function Pid thisProcessPid() to std.process and refer to this from kill(Pid). Should I do PR? PR at https://github.com/D-Programming-Language/phobos/pull/3448
Re: Static constructors guaranteed to run?
On Saturday, 27 June 2015 at 20:16:10 UTC, Timon Gehr wrote: On 06/27/2015 11:54 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Also are static constructors in templated types guaranteed to run for every instantiation? Even if the instantiation is never actually used outside of compile time code, like in an alias or in a UDA? Definitely not. Things inside a template don't even exist if that template is never instantiated. (That wasn't his question.) Ah sorry, I see. In this case I don't know the answer. There might even be a difference between normal CTFE code and is-expressions...
Re: Pure delegate not quite pure?
On Sunday, 28 June 2015 at 09:19:16 UTC, Tofu Ninja wrote:
module main;
import std.stdio;
void main(string[] args)
{
auto d = foo();
writeln(d()); // prints 25
}
auto foo()
{
int x = 4;
pure int delegate() d = delegate()
{
return x*x;
};
writeln(d()); // prints 16
x = 5;
writeln(d()); // prints 25
return d;
}
I can see that after foo returns, then d will truly be pure as
x will no longer be modifiable, but just before that, it seems
d is not actually pure. Is this the intended behavior?
Just guessing: The context is treated as an implicit parameter of
`d` (analogous to `this` for a struct/class). Access to `x`
counts a access through a parameter and therefore doesn't violate
purity.
Re: how to string → uint* ?
On Sunday, 28 June 2015 at 10:29:48 UTC, Mike Parker wrote: On 6/28/2015 7:08 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: In addition to what anonymous said, you might want to raise a bug report with Derelict, because the function signatures are arguable wrong, though that depends on whether Derelict wants to provide a strict one-to-one mapping of the C code, or one that is already somewhat adapted to D: https://github.com/DerelictOrg/DerelictSFML2/blob/master/source/derelict/sfml2/graphics.d#L521-L522 alias da_sfText_setString = void function( sfText*,const( char )* ); The documentation says that this is for ANSI strings, but `char` in D is defined to be a *UTF8* code unit. Instead, the type should be `const(ubyte)*`. I've been mapping D char to C char in Derelict packages for 11 years. It's also what's recommended on the page about interfacing to C[1]. Although I do understand your point, I'm curious if anyone is actually taking the ubyte approach these days? Or has anyone actually encountered a problem with the char-char mapping? Invalid UTF8 in strings currently throws on decoding, but it's being changed to asserts, because it's against specification and therefore (the consequence of) a bug somewhere in the program. One reason for this is to make decoding @nogc, the other is simply correctness: a variable having the type `char[]` should be a guarantee that it contains valid UTF8. I don't know of any actual problems though, but if they happen, they will soon be Errors instead of Exceptions.
Re: how to string → uint* ?
On Sunday, 28 June 2015 at 10:00:37 UTC, anonymous wrote: On Sunday, 28 June 2015 at 01:57:46 UTC, xky wrote: [...] Don't try casting just because you guess it could maybe work. The best documentation for setUnicodeString I could find is this: https://github.com/SFML/CSFML/blob/master/include/SFML/Graphics/Text.h#L243 which is pretty bad. [...] Thank you everybody for answered me! ^_^
