Inherit of attributes
Hi ! http://dpaste.dzfl.pl/2fa3dd2ea834 Why S.init not pure ? Is it expected behavior or bug ? Thanks!
Re: Problem with code coverage. No .lst files?
On Friday, 25 April 2014 at 04:23:45 UTC, Ali Çehreli wrote: On 04/24/2014 08:32 PM, Jeremy DeHaan wrote: added the -cov switch to my unit test build Then you must execute the program. :) Ali I did, but still nothing. I even tried using the switch in a debug build and the same thing happened(or didn't happen I guess). I'm using Mono-D to build if that makes any difference, and I've tried running it both through Mono-D and via the application itself. I'm not sure what to do. :(
Re: Inherit of attributes
On Friday, 25 April 2014 at 07:59:29 UTC, Temtaime wrote: Hi ! http://dpaste.dzfl.pl/2fa3dd2ea834 Why S.init not pure ? Is it expected behavior or bug ? Thanks! Fix http://dpaste.dzfl.pl/03f73cd958f4
Re: Inherit of attributes
Hi, MrSmith ! Yes, i know that, but my question isn't about it. I want to type `pure:` at module's beginning and have all function(in classes, too) declared as pure. I think `pure:` should do it. But it doesn't.
Re: Inherit of attributes
On Friday, 25 April 2014 at 09:08:50 UTC, Temtaime wrote: Hi, MrSmith ! Yes, i know that, but my question isn't about it. I want to type `pure:` at module's beginning and have all function(in classes, too) declared as pure. I think `pure:` should do it. But it doesn't. pure is not a transitive attribute and when applied to aggregates gets ignored, not applied to all of their members
Re: Inherit of attributes
Hi ! Thanks for reply. Why so ? And why @nogc not transitive too ?
Determining protection of another module's member
__traits(getProtection) allows us to know if something is private, protected, etc. But how would one go about determining that from another module? The problem here is if module foo defines a function foofunc that is private, trying to use __traits(getProtection) from another module fails to compile. The problem I'm trying to solve is how to determine if another module's member is private without having to resort to __traits(compiles). If you're wondering how the 2nd module would even know about the existence of that private member, it would be via __traits(allMembers). Thanks in advance, Atila
Re: Const Tuples
On Friday, 25 April 2014 at 11:51:48 UTC, bearophile wrote:
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes some troubles when you use tuples.
Bye,
bearophile
Why would you even expect those to be same types? These 2 types
are also different:
struct A
{
const int x;
}
alias A_ = const(A);
Const Tuples
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes some troubles when you use tuples.
Bye,
bearophile
Re: Const Tuples
Dicebot:
Why would you even expect those to be same types? These 2 types
are also different:
struct A
{
const int x;
}
alias A_ = const(A);
In general a tuple is a higher level data structure compared to a
struct. So it's not unreasonable to expect a Tuple to be more
flexible than a struct.
But in the specific const tuple case I don't know if it's a good
idea to ask for a const tuple to be of the same type of a tuple
with all const fields.
I was just expressing a little frustration :-)
Bye,
bearophile
Re: Const Tuples
On Friday, 25 April 2014 at 12:17:31 UTC, bearophile wrote: In general a tuple is a higher level data structure compared to a struct. So it's not unreasonable to expect a Tuple to be more flexible than a struct. Well, wrong :) std.typecons.Tuple IS a struct - https://github.com/D-Programming-Language/phobos/blob/master/std/typecons.d#L388 But in the specific const tuple case I don't know if it's a good idea to ask for a const tuple to be of the same type of a tuple with all const fields. It would be weird exception of general type system rules with no practical justification I can readily imagine. I was just expressing a little frustration :-) Bye, bearophile
Re: Const Tuples
Dicebot: Well, wrong :) std.typecons.Tuple IS a struct - https://github.com/D-Programming-Language/phobos/blob/master/std/typecons.d#L388 Nope, that's just an implementation detail. They are two quite different data structures. Example: slicing a tuple always has a meaning, while slicing a struct is in general meaningless. Bye, bearophile
Re: Const Tuples
On Friday, 25 April 2014 at 12:42:33 UTC, bearophile wrote: Dicebot: Well, wrong :) std.typecons.Tuple IS a struct - https://github.com/D-Programming-Language/phobos/blob/master/std/typecons.d#L388 Nope, that's just an implementation detail. They are two quite different data structures. Example: slicing a tuple always has a meaning, while slicing a struct is in general meaningless. Bye, bearophile It was what you want it to be, not what it is :) Slicing a struct is absolutely routine thing as struct is just a user-defined aggregate type. std.typecons.Tuple is just a subset of all structs implementing specific behavior. It still acts as struct everywhere when applicable. Don't confuse std.typecons.Tuple and built-in template argument lists. Latter are indeed special type system entities. Former is just a smart struct.
Re: Const Tuples
Dicebot: std.typecons.Tuple is just a subset of all structs implementing specific behavior. It still acts as struct everywhere when applicable. A subset is not the same as the whole set. You are missing something important about what a data structure is. Take a look at your computer science books. Another example: a dynamic array allows several operations, including append at the end and pop from the end. If I define a Stack data structure based on a dynamic array with just its pop/append/empty/length operations, I have defined a new data structure. Bye, bearophile
Re: Const Tuples
I was just expressing a little frustration :-)
An example; despite it looks simple I am missing something:
import std.typecons: Tuple, tuple;
import std.algorithm: reduce;
struct Foo { int x; }
auto foo(in Tuple!(Foo[]) arg, int) {
return tuple(arg[0]);
}
void main() {
int[] data;
Foo[] empty;
auto seed = tuple(empty);
reduce!foo(seed, data);
}
Bye,
bearophile
Re: Const Tuples
On Friday, 25 April 2014 at 12:54:25 UTC, bearophile wrote: Dicebot: std.typecons.Tuple is just a subset of all structs implementing specific behavior. It still acts as struct everywhere when applicable. A subset is not the same as the whole set. You are missing something important about what a data structure is. Take a look at your computer science books. Another example: a dynamic array allows several operations, including append at the end and pop from the end. If I define a Stack data structure based on a dynamic array with just its pop/append/empty/length operations, I have defined a new data structure. Bye, bearophile I am not interested in academic definitions. D is not an academic language (thanks gods!) and expecting it to prioritize formal concepts over mundane pragmatism only leads to frustration. The fact that you can use D rules to emulate certain concept as a user-defined type does not make domain semantics of that type more important than language. It is still a second-class citizen. You don't change language rules by creating new data structures. Type system still must prevail :)
Re: Const Tuples
Dicebot: It would be weird exception of general type system rules with no practical justification I can readily imagine. I partially disagree. It could be useful to have structural typing (http://en.wikipedia.org/wiki/Structural_type_system ) only on tuples (and not on structs), because the formal definition of tuple goes well with structural typing. This also implies the type equivalence of const tuple with a tuple of const fields. Bye, bearophile
Re: Const Tuples
import std.typecons: Tuple, tuple;
import std.algorithm: reduce;
struct Foo { int x; }
auto foo(in Tuple!(Foo[]) arg, int) {
return tuple(arg[0]);
}
void main() {
int[] data;
Foo[] empty;
auto seed = tuple(empty);
reduce!foo(seed, data);
}
I have found a solution:
import std.typecons: Tuple, tuple;
import std.algorithm: reduce;
auto foo(in Tuple!(const(int)[]) arg, int) {
return tuple(arg[0]);
}
void main() {
int[] empty;
Tuple!(const(int)[]) seed;
reduce!foo(seed, [1]);
}
Bye,
bearophile
Re: Const Tuples
On Friday, 25 April 2014 at 11:51:48 UTC, bearophile wrote:
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes some troubles when you use tuples.
Bye,
bearophile
I think it's a bad idea to make these equal for this reason: if
T1 == T2, then you would expect Unqual!T1 == Unqual!T2. However:
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
assert(is(T1 == T2));
alias UnT1 = Unqual!T1; // Tuple!(int, int)
alias UnT2 = Unqual!T2; // Tuple!(const int, const int)
assert(is(UnT1 == UnT2));
Re: Const Tuples
Meta: I think it's a bad idea to make these equal for this reason: if T1 == T2, then you would expect Unqual!T1 == Unqual!T2. However: alias T1 = const Tuple!(int, int); alias T2 = Tuple!(const int, const int); assert(is(T1 == T2)); alias UnT1 = Unqual!T1; // Tuple!(int, int) alias UnT2 = Unqual!T2; // Tuple!(const int, const int) assert(is(UnT1 == UnT2)); If we introduce structural typing for tuples (to make T1 and T2 the same type), then Unqual!T2 is Tuple!(int, int). It's like for a const(const(int)[2]). Bye, bearophile
Re: Const Tuples
On Friday, 25 April 2014 at 13:18:13 UTC, bearophile wrote: Dicebot: It would be weird exception of general type system rules with no practical justification I can readily imagine. I partially disagree. It could be useful to have structural typing (http://en.wikipedia.org/wiki/Structural_type_system ) only on tuples (and not on structs), because the formal definition of tuple goes well with structural typing. This also implies the type equivalence of const tuple with a tuple of const fields. Bye, bearophile Again, you refer to some sort of formal definition of tuple which is not applicable to D. We don't have real tuples in D. There are structures that emulate some of tuple properties and there is a built-in feature that is called tuple but is not one in practice. For your objections to make sense tuple would need to be inroduced as completely new first class type system entity. As this will never happen, discussion of imaginary proper tuple traits is also unapplicable.
Re: On Concurrency
Fibers are more lightweight, they're not kernel objects. Threads are scheduled by kernel (usually). Fibers are better if you can get better resource usage with manual scheduling - less context switches, or don't want to consume resources need by threads.
Re: Chris E. Miller ToolTip (D1)
On Saturday, 12 April 2014 at 10:41:19 UTC, hicman wrote: will the library build for x64? It will build but not true x64. On Friday, 11 April 2014 at 12:33:27 UTC, FrankLike wrote: On Thursday, 14 November 2013 at 16:17:53 UTC, Heinz wrote: You have to manually set the tooltip's max width to a fixed value using the tooltip handle and Win32 API, by doing this you're telling the tooltip object it is a multiline tooltip and from now on it will accept \r\n as end of line: ttip = new ToolTip; SendMessageA(ttip.handle, TTM_SETMAXTIPWIDTH, 0, 250); ttip.setToolTip(find, a=n (not approved)\r\no=n (not outlooked)\r\nt0 (total 0)); That's it, it works (i tested it). By the way, the DFL version on Chris' site is for D1 but there's this version for D2 (i use both): https://github.com/Rayerd/dfl/tree/master/win32/dfl Now, dfl can use the dmd 2.065 you can see the fork : https://github.com/FrankLIKE/dfl fork(from https://github.com/Rayerd/dfl/) Waiting Miller commit it.
Re: On Concurrency
On Fri, 2014-04-25 at 17:10 +, Kagamin via Digitalmars-d-learn wrote: Fibers are more lightweight, they're not kernel objects. Threads are scheduled by kernel (usually). Fibers are better if you can get better resource usage with manual scheduling - less context switches, or don't want to consume resources need by threads. Or to put it another way, fibres (!) are what threads were before the hardware and kernel folks changed the game. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Chris E. Miller ToolTip (D1)
On Thursday, 14 November 2013 at 16:17:53 UTC, Heinz wrote: You have to manually set the tooltip's max width to a fixed value using the tooltip handle and Win32 API, by doing this you're telling the tooltip object it is a multiline tooltip and from now on it will accept \r\n as end of line: ttip = new ToolTip; SendMessageA(ttip.handle, TTM_SETMAXTIPWIDTH, 0, 250); ttip.setToolTip(find, a=n (not approved)\r\no=n (not outlooked)\r\nt0 (total 0)); That's it, it works (i tested it). By the way, the DFL version on Chris' site is for D1 but there's this version for D2 (i use both): https://github.com/Rayerd/dfl/tree/master/win32/dfl Sorry for my tardiness in respond, Heinz. And thanks for the help. By the way, for those out there that are not Windows friendly like me, :-), I used the following to make it work. SendMessageA(ttip.handle, 0x0400 + 24, 0, 250); Since I got Error: undefined identifier TTM_SETMAXTIPWIDTH when building the code. Thanks again, Heinz. josé
AES encryption with openssl bindings
hi everyone. I'm trying to symmetrically encrypt some text using the openssl bindings. My code compiles and fails silently. Clearly there is something very wrong with it - it could be my novice D skills, or my misuse of the openssl binding. auto chunk = new ubyte[](16); foreach(ref x; chunk) x = uniform; AES_KEY wctx; AES_set_encrypt_key(chunk.ptr,128,wctx); string s = virident; ubyte[] b; b = cast(ubyte[]) s; ubyte[] e; AES_encrypt(b.ptr,e.ptr,wctx); ubyte[] d; AES_decrypt(e.ptr,d.ptr,wctx); writefln(%s,d); Any clues? I am a D novice, so any spoonfeeding you could provide would be helpful :) thanks! Brad
Re: AES encryption with openssl bindings
On Fri, 25 Apr 2014 19:06:31 +, brad clawsie wrote: hi everyone. I'm trying to symmetrically encrypt some text using the openssl bindings. My code compiles and fails silently. Clearly there is something very wrong with it - it could be my novice D skills, or my misuse of the openssl binding. auto chunk = new ubyte[](16); foreach(ref x; chunk) x = uniform; AES_KEY wctx; AES_set_encrypt_key(chunk.ptr,128,wctx); string s = virident; ubyte[] b; b = cast(ubyte[]) s; ubyte[] e; AES_encrypt(b.ptr,e.ptr,wctx); ubyte[] d; AES_decrypt(e.ptr,d.ptr,wctx); writefln(%s,d); Any clues? I am a D novice, so any spoonfeeding you could provide would be helpful :) thanks! Brad It doesn't look like you're allocating space for `e` or `d`, e.g. `auto e = new ubyte[](256);`, so those arrays have a length of 0, in which case the encrypt/decrypt functions are just trashing their way through memory.
Re: AES encryption with openssl bindings
Justin Whear: brad clawsie: b = cast(ubyte[]) s; Better to use std.string.representation. It doesn't look like you're allocating space for `e` or `d`, e.g. `auto e = new ubyte[](256);`, so those arrays have a length of 0, in which case the encrypt/decrypt functions are just trashing their way through memory. Thankfully we have slices in D. So better to write little wrapper functions, make them the only public functions in a module and use them only. Bye, bearophile
Re: Const Tuples
Dicebot: For your objections to make sense tuple would need to be inroduced as completely new first class type system entity. As this will never happen, I think first class tuples will happen in D, because the current tuple situation is quite bad. But this thread is not about built-in tuples, here we are discussing about possible improvements to the Phobos implementation of tuples. A possible solution is an optional @structural attribute for structs that gives structural typing to one struct (that will be used as underlying implementation for library-defined tuples. Bye, bearophile
