Re: function is not function
On Friday, September 21, 2012 12:59:31 Ellery Newcomer wrote:
> solution is to use std.traits, but can someone explain this to me?
>
> import std.stdio;
>
> void main() {
> auto a = {
> writeln("hi");
> };
> pragma(msg, typeof(a)); // void function()
> pragma(msg, is(typeof(a) == delegate)); // nope!
> pragma(msg, is(typeof(a) == function)); // nope!
> }
Sorry if this ends up being a double-post, but the post I made hours ago
doesn't seem to be showing up, so I'm posting it again:
http://stackoverflow.com/questions/11067972
- Jonathan M Davis
Re: function is not function
On 09/21/2012 10:41 PM, Ellery Newcomer wrote: On 09/21/2012 01:17 PM, bearophile wrote: pragma(msg, is(typeof(a) == function)); // nope! code in pyd suggests this evaluated to true once upon a time. I don't think it ever did. It is just very easy to get wrong.
Re: function is not function
On 09/21/2012 01:10 PM, Ali Çehreli wrote:
You have probably tried the following already:
pragma(msg, is(typeof(a) == void function()));
No, but that's also not very generic.
void main() {
auto a = {
return 1;
};
pragma(msg, is(typeof(a) == void function())); // nope!
pragma(msg, typeof(a)); // void function() pure nothrow @safe
}
guess what I'm fighting with just now
Re: function is not function
On 09/21/2012 01:17 PM, bearophile wrote: pragma(msg, is(typeof(a) == function)); // nope! code in pyd suggests this evaluated to true once upon a time.
Re: function is not function
Ellery Newcomer:
pragma(msg, typeof(a)); // void function()
Maybe pragma(msg) needs to print function pointer types with a
"*", to help remember it's a pointer:
int foo1() pure nothrow @safe { return 0; }
void main() {
static assert(is(typeof(foo1) == function));
auto foo2 = { return 0; };
static assert(is(typeof(*foo2) == function));
pragma(msg, typeof(foo1));
pragma(msg, typeof(foo2));
}
Prints:
pure nothrow @safe int()
int function() pure nothrow @safe
From such printout I am not able to tell the first one is a
function type and the second is the type of a function pointer :-(
Bye,
bearophile
Re: function is not function
Ellery Newcomer:
import std.stdio;
void main() {
auto a = {
writeln("hi");
};
pragma(msg, typeof(a)); // void function()
pragma(msg, is(typeof(a) == delegate)); // nope!
pragma(msg, is(typeof(a) == function)); // nope!
}
There is a subtle difference between function type, type of
function pointer and delegate type.
int foo1() { return 0; }
void main() {
static assert(is(typeof(foo1) == function));
auto foo2 = { return 0; };
static assert(is(typeof(*foo2) == function));
}
Bye,
bearophile
Re: function is not function
On 09/21/2012 12:59 PM, Ellery Newcomer wrote:
solution is to use std.traits, but can someone explain this to me?
import std.stdio;
void main() {
auto a = {
writeln("hi");
};
pragma(msg, typeof(a)); // void function()
pragma(msg, is(typeof(a) == delegate)); // nope!
pragma(msg, is(typeof(a) == function)); // nope!
}
You have probably tried the following already:
pragma(msg, is(typeof(a) == void function()));
Regardless, I think it is a bug because the documentation says that the
'function' keyword alone should work:
http://dlang.org/expression.html#IsExpression
is ( Type == TypeSpecialization )
The condition is satisfied if Type is semantically correct and is the
same type as TypeSpecialization.
If TypeSpecialization is one of struct union class interface enum
function delegate const immutable shared then the condition is satisifed
if Type is one of those.
Ali
function is not function
solution is to use std.traits, but can someone explain this to me?
import std.stdio;
void main() {
auto a = {
writeln("hi");
};
pragma(msg, typeof(a)); // void function()
pragma(msg, is(typeof(a) == delegate)); // nope!
pragma(msg, is(typeof(a) == function)); // nope!
}
Re: Problem with environ variable (Mac OS X)
On Friday, 21 September 2012 at 17:02:50 UTC, Jacob Carlborg wrote: On 2012-09-21 16:42, Chris wrote: The only drawback is the lack of a fully-fledged cross-platform GUI, but that's a different story ... Have a look at DWT, it's a port of the Java library SWT: https://github.com/d-widget-toolkit/dwt http://dsource.org/projects/dwt I'm currently working on the Mac OS X port. I know of DWT, but being a Mac user I am still not able to benefit from it as I would like to. But maximum respect that you are working on it. Keep it up!
Re: Problem with environ variable (Mac OS X)
On 2012-09-21 16:42, Chris wrote: The only drawback is the lack of a fully-fledged cross-platform GUI, but that's a different story ... Have a look at DWT, it's a port of the Java library SWT: https://github.com/d-widget-toolkit/dwt http://dsource.org/projects/dwt I'm currently working on the Mac OS X port. -- /Jacob Carlborg
Re: Passing associative array to another thread
On 2012-09-21 16:33, Martin Drasar wrote: Hi, I am using the std.concurrency module and I would like to send an associative array to another thread. If I try this: string[string] aa; someThread.send(aa); I get: Aliases to mutable thread-local data not allowed. And if I try to use this: immutable(string[string]) aa; someThread.send(aa); I get: /usr/include/d/dmd/phobos/std/variant.d(539): Error: *p is not mutable which is because the send() creates a Message struct that stores the data in a Variant. And now I am stuck, because I do not have any idea what to do. Any advice? Perhaps declaring the associative array as "shared". An alternative would be to serialize the aa, pass it to another thread, and deserialize it. That would though create a copy. -- /Jacob Carlborg
Re: Problem with environ variable (Mac OS X)
On Friday, 21 September 2012 at 09:50:06 UTC, Jacob Carlborg wrote: On 2012-09-21 10:56, Chris wrote: Thanks, that's cool. I really need something like that, because I still use a lot of features that are deprecated by now and are all over the place. The reason for this is that my project developed so fast and grew so big in a short period of time (D speeds up development) that it is hard to trace down all deprecated methods and replace them. Also, the library seems to be changing all the time anyway, so who knows whether or not the new methods will be deprecated again in a few months' time. But as the days are getting shorter I might find the time to skim through the code and finally do the dirty work I keep putting off. That's been a quite annoying problem of D. But things have settle down quite a lot in recent times. Hopefully there shouldn't be that much breaking code these days. But if you're relaying on a bug that was fixed it will still break your code. Yeah, I see. I didn't realize it was a fixed bug, because I had checked process.d online and thought "Well, it should work". It didn't occur to me that the environ-thing for Mac OS X wasn't included in older versions. But I'll know better the next time! I hope you are right and things have settled down now, because I would really like to keep on using D and see it take off someday. I have been able to easily integrate my D code into Python, C, Lua (and now hopefully Java) programs and access C libraries easily from D, which - apart from all the nice features the language has to offer - is a real big plus. The only drawback is the lack of a fully-fledged cross-platform GUI, but that's a different story ...
Passing associative array to another thread
Hi, I am using the std.concurrency module and I would like to send an associative array to another thread. If I try this: string[string] aa; someThread.send(aa); I get: Aliases to mutable thread-local data not allowed. And if I try to use this: immutable(string[string]) aa; someThread.send(aa); I get: /usr/include/d/dmd/phobos/std/variant.d(539): Error: *p is not mutable which is because the send() creates a Message struct that stores the data in a Variant. And now I am stuck, because I do not have any idea what to do. Any advice? Thanks, Martin
Re: About std.ascii.toLower
On Friday, September 21, 2012 14:10:25 monarch_dodra wrote: > I did not know conv's to did cast validation. For conversions which can be done with both casting and std.conv.to, std.conv.to does runtime checks wherever a narrowing conversion would take place and throws if the conversion would lose precision. - Jonathan M Davis
Re: About std.ascii.toLower
On Friday, 21 September 2012 at 11:25:54 UTC, Jonathan M Davis wrote: On Friday, September 21, 2012 13:18:01 monarch_dodra wrote: Related, could "toChar" be considered for inclusion? I think it would be a convenient tool for validation. I certainly would be against adding it. I think that it's a relatively uncommon use case and considering how easy it is to just write the function yourself, the functionality gain is minimal. I just don't think that it carries it's weight as far as the standard library goes. But I don't know how others like Andrei would feel. That said, if we go that way, we might as well just have a more generic safeCast in std.conv or something: You're basically asking for a version of std.conv.to which uses assertions instead of exceptions. - Jonathan M Davis I know my ideas usually get shot down, but I usually learn a LOT from your answers, so sorry for insisting. I did not know conv's to did cast validation. In my defense, the doc is actually missing: http://dlang.org/phobos/std_conv.html I made a doc pull request so that it would appear. https://github.com/D-Programming-Language/phobos/pull/811
Re: About std.ascii.toLower
On Friday, September 21, 2012 13:18:01 monarch_dodra wrote: > Related, could "toChar" be considered for inclusion? I think it > would be a convenient tool for validation. I certainly would be against adding it. I think that it's a relatively uncommon use case and considering how easy it is to just write the function yourself, the functionality gain is minimal. I just don't think that it carries it's weight as far as the standard library goes. But I don't know how others like Andrei would feel. > That said, if we go that way, we might as well just have a more > generic safeCast in std.conv or something: You're basically asking for a version of std.conv.to which uses assertions instead of exceptions. - Jonathan M Davis
Re: About std.ascii.toLower
On Friday, 21 September 2012 at 10:45:42 UTC, Jonathan M Davis
wrote:
On Friday, September 21, 2012 12:38:07 monarch_dodra wrote:
On Friday, 21 September 2012 at 10:23:39 UTC, Jonathan M Davis
wrote:
> On Friday, September 21, 2012 11:00:31 monarch_dodra wrote:
>> What do you (you two) think of my proposition for a
>> "std.strictascii" module?
>
> I don't think that it's at all worth it. It's just duplicate
> functionality in
> order to avoid a cast.
(and contract)
If that's what you want, it's easy enough to create a helper
function which
you use instead of a cast which does the contract check as
well. e.g.
char toChar(dchar c)
{
assert(isAscii(c));
return cast(char)c;
}
foreach(ref char c; str)
c = toChar(std.ascii.toLower(c));
It should be completely optimized out with -release and -inline.
- Jonathan M Davis
That's a real good idea. Also, I find it is these kinds of
situations where UFCS really shines (IMO):
foreach(i, c; s1)
cs[i] = c.toUpper().toChar();
I love this syntax.
Related, could "toChar" be considered for inclusion? I think it
would be a convenient tool for validation.
/*
* Casts dchar to a char.
*
* Preconditions:
* $(D c) must be representable in a single char.
*/
char toChar(dchar c)
{
assert(c < 256, "toChar: Input too large for char");
return cast(char)c;
}
That said, if we go that way, we might as well just have a more
generic safeCast in std.conv or something:
T safeCast(T, U)(U i)
if(isBasicType!T && isBasicType!U)
{
assert(cast(T)i == i, "safeCast: Cast failed");
return cast(T)i;
}
foreach(i, c; s1)
cs[i] = c.toUpper().safeCast!char();
Hum... yeah... I don't know...
I seem to be typing faster than I can really think of the
consequences of such a function.
Re: About std.ascii.toLower
On Friday, September 21, 2012 12:38:07 monarch_dodra wrote:
> On Friday, 21 September 2012 at 10:23:39 UTC, Jonathan M Davis
>
> wrote:
> > On Friday, September 21, 2012 11:00:31 monarch_dodra wrote:
> >> What do you (you two) think of my proposition for a
> >> "std.strictascii" module?
> >
> > I don't think that it's at all worth it. It's just duplicate
> > functionality in
> > order to avoid a cast.
>
> (and contract)
If that's what you want, it's easy enough to create a helper function which
you use instead of a cast which does the contract check as well. e.g.
char toChar(dchar c)
{
assert(isAscii(c));
return cast(char)c;
}
foreach(ref char c; str)
c = toChar(std.ascii.toLower(c));
It should be completely optimized out with -release and -inline.
- Jonathan M Davis
Re: About std.ascii.toLower
On Friday, 21 September 2012 at 10:23:39 UTC, Jonathan M Davis wrote: On Friday, September 21, 2012 11:00:31 monarch_dodra wrote: What do you (you two) think of my proposition for a "std.strictascii" module? I don't think that it's at all worth it. It's just duplicate functionality in order to avoid a cast. (and contract) - Jonathan M Davis Somehow, I expected that reply, but I had to ask anyways :D Thanks.
Re: About std.ascii.toLower
On Friday, September 21, 2012 11:00:31 monarch_dodra wrote: > What do you (you two) think of my proposition for a > "std.strictascii" module? I don't think that it's at all worth it. It's just duplicate functionality in order to avoid a cast. - Jonathan M Davis
Re: Problem with environ variable (Mac OS X)
On 2012-09-21 10:56, Chris wrote: Thanks, that's cool. I really need something like that, because I still use a lot of features that are deprecated by now and are all over the place. The reason for this is that my project developed so fast and grew so big in a short period of time (D speeds up development) that it is hard to trace down all deprecated methods and replace them. Also, the library seems to be changing all the time anyway, so who knows whether or not the new methods will be deprecated again in a few months' time. But as the days are getting shorter I might find the time to skim through the code and finally do the dirty work I keep putting off. That's been a quite annoying problem of D. But things have settle down quite a lot in recent times. Hopefully there shouldn't be that much breaking code these days. But if you're relaying on a bug that was fixed it will still break your code. -- /Jacob Carlborg
Re: About std.ascii.toLower
On Thursday, 20 September 2012 at 17:32:52 UTC, bearophile wrote:
Jonathan M Davis:
Functions which operate on ASCII characters. All of the
functions in std.ascii accept unicode characters but
effectively ignore them. All isX functions return false for
unicode characters, and all toX functions do nothing to unicode
characters.<
So now I'd like a new set of functions designed for ASCII text,
with contracts to refuse not-ASCII things ;-)
Thank you for the answers Jonathan.
Bye,
bearophile
What do you (you two) think of my proposition for a
"std.strictascii" module?
The signatures would be:
char toLower(dchar c);
And the implementations be like:
char toLower(dchar c)
in
{
assert(c.std.ascii.isAscii());
}
body
{
cast(char) c.std.ascii.toLower();
}
The rational for taking a dchar as input is so that it's own
input can be correctly validated, and so that it can easilly
operate with foreach etc, doing the cast internally. The returned
value would be pre-cast to char.
Usage:
import std.stdio;
import std.strictascii;
void main(){
string s1 = "axbacxf";
string s2 = "àxbécxf";
char[] cs = new char[](7);
//bearophile use case: no casts
foreach(i, c; s1)
cs[i] = c.toUpper();
//illegal use case: correct input validation
foreach(i, c; s1)
cs[i] = c.toUpper(); //in assert
}
It doesn't add *much* functionality, and arguably, it is a
specialized functionality, but there are usecases where you want
to operate ONLY on ascii, as pointed out by bearophile.
Just curious if I should even consider investing some effort in
this.
Re: Problem with environ variable (Mac OS X)
On Friday, 21 September 2012 at 06:16:33 UTC, Jacob Carlborg wrote: On 2012-09-20 21:34, Chris wrote: Thanks a million, Jacob! I have just tested it with the latest version of dmd and it works. No problem. You can use DVM if you need the to keep the old version of the compiler. https://bitbucket.org/doob/dvm Thanks, that's cool. I really need something like that, because I still use a lot of features that are deprecated by now and are all over the place. The reason for this is that my project developed so fast and grew so big in a short period of time (D speeds up development) that it is hard to trace down all deprecated methods and replace them. Also, the library seems to be changing all the time anyway, so who knows whether or not the new methods will be deprecated again in a few months' time. But as the days are getting shorter I might find the time to skim through the code and finally do the dirty work I keep putting off.
how to get version identifiers set during compilation?
how to get version identifiers set during compilation?
ideally would be something like:
enum versions=VersionFlags;//returns ["OSX","debug"] for example
one use case is to have arbitrary logic on versions without
requiring new syntax.
eg:
static if(VersionFlags.canFind("OSX") &&
!VersionFlags.canFind("debug") ){...}
but there are other uses.
related question:
how to get compilation flags that were set?
eg search paths
It doesn't seem currently possible, is there interest in having
it implemented?
perhaps in std.compiler?
