Getting a class' name, but not fully qualified?
As the title says, I was wondering if there was a way to get the classes name at runtime, but not its fully qualified name. I want JUST the name of the class only. Obviously I could get the fully qualified name from the classinfo and then split it up to get the name of the class, but I don't want to do all that at runtime. Is this possible or am I out of luck?
Re: Problem with taking inout, const references
On 03/26/2014 10:29 PM, Uranuz wrote: I haven't send a bug so I'm not familiar with it. How could I do it? Go to https://d.puremagic.com/issues/ Click "File an Issue" (but you may need to "Open a New Account" first). Product: D Component: DMD Version: D2 Importance: P3 normal A descriptive title... Additional Comments: the reduced code etc. Then click "Commit". Thank you, :) Ali
Re: D project structure
Since I use unit-threaded for my unit tests, I place them all in a directory called "tests" at the root directory of the project. I haven't written integration tests yet for any D project and was wondering myself what I would do. Mine might be a special case, I don't know who else uses a unit testing library. Atila On Wednesday, 26 March 2014 at 16:13:15 UTC, Russel Winder wrote: Is it the case that the Dub recommended project structure is in fact the canonical D project structure? The Dub recommended structure doesn't mention test code as opposed to application/library source code, is it the case that the assumption is that all tests are in the modules using built-in unittest and that there are never any external tests? What about integration and system testing? cf. The canonical jvm language project structure is src/main/ src/test/ src/integtest/ Thanks.
Re: Problem with taking inout, const references
Type is a compile-time concept; there is no difference between the compiled mutable versus const versions of your inout function. So, there is no need for more than one compilation. Yes. It's my mistake. For CPU there is only data (that are sequence of bits) and comands (that are sequence of bits too). Type is human interpretation of meaning of these bits. The problem is, when the foreach variable is ref, the type gains a const as well. Unless there is a reason for that we should file a bug. So problem is in foreach operator but not in *inout* itself. I haven't send a bug so I'm not familiar with it. How could I do it?
Why are compile-time constraints checked with an (inout int = 0) lambda in Phobos?
Why the (inout int = 0) instead of an empty parameter list? I checkout how isInputRange was implemented and I copied the idiom, but I'd like to know why it's like that instead of cargo culting. Thanks, Atila
Re: is there any trait to check if variable is __gshared?
On Wed, 26 Mar 2014 11:52:29 -0400, ketmar wrote: i think that '__gshared' should be part of type info, just like 'shared' is. variable can't be both 'shared' and '__gshared' anyway. The point of __gshared is it's an override of the type info. There are some cases where you need shared data, but you don't want the type system to know that. Usually it's for "safety checks off" code. -Steve
How to Distinguish between a Lambda and a Function Template at Compile Time
Is this a safe way to distinguish between function literals and
function literal templates at compile time?
import std.functional;
import std.traits;
template makeFunAlias(alias F)
if (isSomeFunction!(typeof(F)) || is(typeof(F) == void))
{
static if (is(typeof(F) == void))
{
alias makeFunAlias = unaryFun!(F!char);
}
else
{
alias makeFunAlias = unaryFun!F;
}
}
void main()
{
alias test1 = makeFunAlias!((char c) => c);
alias test2 = makeFunAlias!(function(char c) => c);
alias test3 = makeFunAlias!(c => c);
}
sending a delegate through extern (C)
Hi,
I'm trying to send a delegate to a modified version of druntime's GC as
follows:
struct GC {
static void onCollect(void* dg)
{
gc_onCollect(cast(void*)dg);
}
...
my code:
extern (C) extern __gshared void collecting(void* p, size_t sz){
import std.stdio;
writeln(p, sz);
}
GC.onCollect(cast(void*)&collecting);
and the caller in gc.d casts this to a function(void*, size_t) before
sending the parameters.
I get the following:
object.Error: Access Violation
0x00536A9D in gc_onCollect
0x0051FA18 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x0051F9EB in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(ch
ar[][])*).runAll()
0x0051F904 in _d_run_main
0x00446258 in main
0x0055C991 in mainCRTStartup
0x7513495D in BaseThreadInitThunk
0x770B98EE in RtlInitializeExceptionChain
0x770B98C4 in RtlInitializeExceptionChain
There are still tasks running at exit.
Error executing command run: Program exited with code 1
I'm wondering, why doesn't this execute the callback? I've tried many
combinations of types but it looks like the pointer isn't accessible...
Thanks!
Re: Problem with taking inout, const references
On 03/26/2014 12:17 PM, Uranuz wrote:
> I modified this with casting pointer to pointer to *inout* and it
> compiles then.
>
> inout(Cookie)* opBinaryRight(string op)(string name) inout if(op == "in")
> {foreach( ref inout(Cookie) c; _cookies )
> if( c.name == name )
> return cast(inout(Cookie)*) &c; //Error is here
> return null;
> }
I think it is a bug then. I only now understand the problem. Here is a
reduced case:
class C
{
int[1] arr;
inout(int)* foo() inout
{
foreach (ref e; arr) {
static assert(is (typeof(e) == inout(const(int; // WAT?
return &e;
}
}
}
void main()
{
(new C).foo();
}
The problem is, when the foreach variable is ref, the type gains a const
as well. Unless there is a reason for that we should file a bug.
Another workaround for you is using the foreach index:
{foreach(i, ref inout(Cookie) c; _cookies ) // NOTE i
if( c.name == name )
return &_cookies[i];// NOTE i
return null;
}
> As I think compiler may be should create const version and mutable
> version of this function.
Type is a compile-time concept; there is no difference between the
compiled mutable versus const versions of your inout function. So, there
is no need for more than one compilation.
> In case when it's mutable it should return pointer to mutable
> pointer to *const* data when function is const.
Makes sense and it should be checked at compile time.
> I don't understand why compiler produce pointer to const,
I think that's a bug.
> In case when all is treated like const
The body of an inout function must not mutate the object because the
same body supports the non-mutable cases as well. So, it is acceptable
for the compiler to compile as if it's const. However, as you say, the
interface of the function still obeys the actual types used in the program.
You are right. I think it is just a bug.
Ali
Re: D project structure
On 26/03/14 17:12, Russel Winder wrote: The Dub recommended structure doesn't mention test code as opposed to application/library source code, is it the case that the assumption is that all tests are in the modules using built-in unittest and that there are never any external tests? I don't think there's anything about dub that stops you having arbitrary build targets in arbitrary directories, so you could readily place the source for a test application (or multiple applications) in different directories. This is what I did in my first project to use Dub: https://github.com/WebDrake/Dgraph/blob/master/package.json The programs in the subdirectories of util/ are individual test programs -- in this case benchmarks, but you could readily extend the idea. In my particular case I think it'd probably have been better just to directly specify the exact source files for each app, which is almost certainly possible, I just didn't do it ;-) But this approach seems a good one for more complex test applications that are effectively whole projects in their own right.
Re: Transforming a C/C++ project to D
On 2014-03-26 19:38, Andrew Edwards wrote: For the rest of us who do not use Tango, will DStep ever offer an option for use with just the phobos? No, not unless someone else does the work. Although I don't see the problem. Pre-compiled binaries are available or it can compile it with Dub, which will handle all dependencies automatically. -- /Jacob Carlborg
Re: Problem with taking inout, const references
I modified this with casting pointer to pointer to *inout* and it
compiles then.
inout(Cookie)* opBinaryRight(string op)(string name) inout if(op
== "in")
{ foreach( ref inout(Cookie) c; _cookies )
if( c.name == name )
return cast(inout(Cookie)*) &c; //Error is here
return null;
}
As I think compiler may be should create const version and
mutable version of this function. In case when it's mutable it
should return pointer to mutable pointer to *const* data when
function is const. In first case it will be able to modify
variable from outside using this pointer to mutable. Otherwise if
pointer to *const* produced modification is not allowed. I don't
understand why compiler produce pointer to const, when inout
"converts" to mutable. I think that compiler should check that
object field is not modified inside it's const method, but I
don't understand why it produces pointer to nonconst in case when
object field shouldn't be const.
In case when all is treated like const I don't understand how
*inout* could be useful to get mutable references and pointers as
result of *inout* method when object (and it's fields) are
mutable. Is this behaviour forbidden for some reason that I
don't know?
Re: Transforming a C/C++ project to D
On 3/26/14, 1:51 PM, Jacob Carlborg wrote: You can use Adam D. Ruppe's tool dtoh, currently being reviewed [1], to create C bindings for D code. You can also use DStep [2] to create D bindings for the C code. [1] http://forum.dlang.org/thread/lgspgg$2i8l$1...@digitalmars.com [2] https://github.com/jacob-carlborg/dstep For the rest of us who do not use Tango, will DStep ever offer an option for use with just the phobos?
Re: is there any trait to check if variable is __gshared?
Yes, please resolve it as a duplicate of the other bug (bug 12474). done.
Re: Transforming a C/C++ project to D
On 2014-03-26 17:17, Russel Winder wrote: I may have missed something in Google searches but… I am looking at a GTK+2 project that was originally C, got transformed somewhat (and a bit badly) into a mix of C and C++. I can either move it the whole thing to C++14 or try to turn it into a D code. Revolutionary change is likely out of the question simply because it is a bigish project and too big an "elephant task". If however it is possible to incrementally move parts of the whole to D that is much more likely to happen. Sure, it should be possible to incrementally move a project from C to D. It depends a bit on how the project structure looks like, but you should be able to port object files one at the time to D. Then link it with the rest of the object files. You can use Adam D. Ruppe's tool dtoh, currently being reviewed [1], to create C bindings for D code. You can also use DStep [2] to create D bindings for the C code. [1] http://forum.dlang.org/thread/lgspgg$2i8l$1...@digitalmars.com [2] https://github.com/jacob-carlborg/dstep -- /Jacob Carlborg
Re: is there any trait to check if variable is __gshared?
On 03/26/2014 10:44 AM, ketmar wrote: Ok filed argh. should i (or moderators) close my report as duplicate then? Yes, please resolve it as a duplicate of the other bug (bug 12474). Ali
Re: is there any trait to check if variable is __gshared?
Please file this as an enhancement request to bugzilla[1]. Thanks! just did it: https://d.puremagic.com/issues/show_bug.cgi?id=12475 please check if i did it right and feel free to correct anything. i'm not english-speaking creature and i have no big expirience in doing public requests to big project. tnx.
Re: is there any trait to check if variable is __gshared?
Ok filed argh. should i (or moderators) close my report as duplicate then?
Re: Problem with taking inout, const references
On 03/26/2014 01:21 AM, Uranuz wrote:
> If inout is treated as const does it mean that in this operator I can't
> assign new value to cookie object.
I have not investigated the compiler code but the following is very
logical to me.
inout is not a template mechanism. The code gets compiled once. What
happens is, the inout from some variable is transferred to some other
variable(s).
Since inout must work with mutable, const, and immutable, and since
const binds to all three, it is easy for the compiler to assume inout is
const inside the code and reject code that tries to modify an inout
variable (even if inout is 'mutable' for some calls to the function).
After compiling the code, the compiler also ensures that the inout that
is returned from the function is compatible with the calling code. For
example, if the source inout array were immutable, a slice of it should
not be assigned to a mutable slice at the caller site:
inout(int)[] foo(inout(int)[] arr)
{
return arr;
}
immutable(int)[] imm = // ...;
int[] result = foo(imm);// ERROR
> In this case it means that I still
> should make separate class method with the same body to woraround this.
> I think that it's a bug. Am I right?
It is not a bug. If the member function makes modifications to the
object, it cannot be inout, because it can work only with mutable objects.
Ali
Re: is there any trait to check if variable is __gshared?
On 3/26/14, Andrej Mitrovic wrote: > Please file this as an enhancement request to bugzilla[1]. Thanks! > > [1] : https://d.puremagic.com/issues/enter_bug.cgi?product=D Ok filed as: https://d.puremagic.com/issues/show_bug.cgi?id=12474
Re: is there any trait to check if variable is __gshared?
On 3/26/14, ketmar wrote: > is there any trait to check if variable is __gshared? typeof() > for '__gshared int' returns just 'int', whereas for 'shared int' > it returns 'shared(int)'. can i check for __gshared storage class > somehow? Please file this as an enhancement request to bugzilla[1]. Thanks! [1] : https://d.puremagic.com/issues/enter_bug.cgi?product=D
Transforming a C/C++ project to D
I may have missed something in Google searches but… I am looking at a GTK+2 project that was originally C, got transformed somewhat (and a bit badly) into a mix of C and C++. I can either move it the whole thing to C++14 or try to turn it into a D code. Revolutionary change is likely out of the question simply because it is a bigish project and too big an "elephant task". If however it is possible to incrementally move parts of the whole to D that is much more likely to happen. Has any done this incremental move type thing before and had success? Thanks. -- 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
D project structure
Is it the case that the Dub recommended project structure is in fact the canonical D project structure? The Dub recommended structure doesn't mention test code as opposed to application/library source code, is it the case that the assumption is that all tests are in the modules using built-in unittest and that there are never any external tests? What about integration and system testing? cf. The canonical jvm language project structure is src/main/ src/test/ src/integtest/ Thanks. -- 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: is there any trait to check if variable is __gshared?
Is the -vtls compiler switch enough? it's calling the external utility. i can use full blown D parser than. what i want is to be able to do that thing in compile time, just with metaprogramming.
Re: is there any trait to check if variable is __gshared?
On Wednesday, 26 March 2014 at 15:58:32 UTC, bearophile wrote: Is the -vtls compiler switch enough? The JSON output with -X will also tell you if it is gshared. But in both cases you'd have to run the compiler twice and read the output instead of just getting the info at compile time from inside D.
Re: is there any trait to check if variable is __gshared?
ketmar: 'cause i need only 'old-style' globals in my console. there is no guarantee from which thread console command will be executed, and i don't really need TLS vars in it. that is the 'tech requirement'. Is the -vtls compiler switch enough? Bye, bearophile
Re: is there any trait to check if variable is __gshared?
But why do you need to avoid the thread-local ones while crating your wrappers? 'cause i need only 'old-style' globals in my console. there is no guarantee from which thread console command will be executed, and i don't really need TLS vars in it. that is the 'tech requirement'. (If your need is real, you can ask for the trait in the main D newsgroup). alas, i can't really explain why this is necessary for everyone (to be included in language). except that if we have such powerfull metaprogramming abilities we should be able to access any piece of 'type definition' (ok, technically __gshared is an attribute, i think) info that compiler knows. i think that '__gshared' should be part of type info, just like 'shared' is. variable can't be both 'shared' and '__gshared' anyway. i'll think about asking that though.
Re: is there any trait to check if variable is __gshared?
ketmar: i need to iterate over all module variables and 'register' (read: generate some wrappers) only for shared and __gshared ones, avoiding TLS. But why do you need to avoid the thread-local ones while crating your wrappers? (If your need is real, you can ask for the trait in the main D newsgroup). Bye, bearophile
Re: is there any trait to check if variable is __gshared?
Why do you need it? i need to iterate over all module variables and 'register' (read: generate some wrappers) only for shared and __gshared ones, avoiding TLS. sure i can write a big WARNING in documentation, but i want to check it in compile time too. that's kind of 'in-game command console' module and i want to be able to write: mixin(CMDCON_REGISTER_VARS!modulename); which will iterate over all module vars and 'register' in console those which names stars with 'cvar_' and which are either 'shared' or '__gshared'. sorry for the messy explanation.
Re: Generate toString() method at compile time
On Wednesday, 26 March 2014 at 15:01:35 UTC, Ary Borenszweig
wrote:
A small question: tupleof seems to return a tuple of values.
Most accurately, it returns a tuple of variables (it is a bit
magical). So
struct A { int a; string b; }
the tupleof there is int a; string b - variables with different
types and different names. The stringof works as if you said
A.a.stringof - it fetches the name of the variable.
The slice I did on it cuts off the "this." from the full name,
leaving just the name.
Value to string is done with the to!string function, .stringof
always works at compile time.
Re: Generate toString() method at compile time
that's what i did in a hurry. it seems to work, but the code is
very ugly.
[/code]
import std.conv, std.stdio, std.string, std.traits;
string gen_printer (alias cn) () {
string res = "override string toString () {\nstring res = `" ~
cn.stringof ~ "(`;\n";
bool need_comma = false;
foreach (i, m; __traits(derivedMembers, cn)) {
static if (!isCallable!(__traits(getMember, cn, m)) /*&& m !=
"Monitor"*/) {
if (need_comma) res ~= `res ~= ", ";`; else need_comma =
true;
res ~= "res~=`" ~ m ~ " = `~to!string(" ~ m ~ ");";
}
}
res ~= "res~=`)`;\n";
res ~= "return res;\n}\n";
return res;
}
class Foo {
int x;
int y;
void test () {}
mixin(gen_printer!Foo);
}
void main () {
auto foo = new Foo;
foo.x = 1;
foo.y = 2;
writefln("%s", foo); // prints "Foo(x = 1, y = 2)"
}
[/code]
Re: Generate toString() method at compile time
On Wednesday, 26 March 2014 at 14:16:08 UTC, Ary Borenszweig
wrote:
I'd like to generate a toString() method for my classes. For
example:
Try this:
override string toString() {
import std.conv;
string s;
s ~= this.classinfo.name ~ "(";
foreach(idx, val; this.tupleof) {
if(idx) s ~= ", ";
s ~= this.tupleof[idx].stringof[5 .. $];
s ~= " = ";
s ~= to!string(val);
}
s ~= ")";
return s;
}
add that method to Foo.
$ ./test58
test58.Foo(x = 1, y = 2)
Re: Generate toString() method at compile time
On 3/26/14, 11:47 AM, Adam D. Ruppe wrote:
On Wednesday, 26 March 2014 at 14:16:08 UTC, Ary Borenszweig wrote:
I'd like to generate a toString() method for my classes. For example:
Try this:
override string toString() {
import std.conv;
string s;
s ~= this.classinfo.name ~ "(";
foreach(idx, val; this.tupleof) {
if(idx) s ~= ", ";
s ~= this.tupleof[idx].stringof[5 .. $];
s ~= " = ";
s ~= to!string(val);
}
s ~= ")";
return s;
}
add that method to Foo.
$ ./test58
test58.Foo(x = 1, y = 2)
A small question: tupleof seems to return a tuple of values. So
this.tupleof[idx] would return a value. However when you do
this.tupleof[idx].stringof that somehow gets the name of the field.
Shouldn't it return the name of the value? I'm confused.
Re: Generate toString() method at compile time
On Wednesday, 26 March 2014 at 14:53:55 UTC, Ary Borenszweig wrote: Thanks! That's pretty neat. It seems I was missing "tupleof". Yea, there's other options too like __traits(derivedMembers) if(!is(__traits(getMember...)) == function) and stuff like that, filtering like bearophile said, I just think tupleof is the easiest option for this.
Re: is there any trait to check if variable is __gshared?
ketmar: is there any trait to check if variable is __gshared? There isn't. It could be added to D if there's a significant reason. Why do you need it? Bye, bearophile
Re: Generate toString() method at compile time
On 3/26/14, 11:47 AM, Adam D. Ruppe wrote:
On Wednesday, 26 March 2014 at 14:16:08 UTC, Ary Borenszweig wrote:
I'd like to generate a toString() method for my classes. For example:
Try this:
override string toString() {
import std.conv;
string s;
s ~= this.classinfo.name ~ "(";
foreach(idx, val; this.tupleof) {
if(idx) s ~= ", ";
s ~= this.tupleof[idx].stringof[5 .. $];
s ~= " = ";
s ~= to!string(val);
}
s ~= ")";
return s;
}
add that method to Foo.
$ ./test58
test58.Foo(x = 1, y = 2)
Thanks! That's pretty neat. It seems I was missing "tupleof".
Re: is there any trait to check if variable is __gshared?
I don't think so. Since __gshared isn't part of the type (unlike shared), you can't check for it with is(typeof()) and .stringof is only giving me the name.
Re: Generate toString() method at compile time
Ary Borenszweig: I tried using getAllMembers, but that also gives me all methods of Foo. I just want the fields. You can try to filter the results of getAllMembers. Bye, bearophile
Generate toString() method at compile time
Hi,
I'd like to generate a toString() method for my classes. For example:
---
import std.stdio;
class Foo {
int x;
int y;
// mixin ...?
}
void main() {
auto foo = new Foo;
foo.x = 1;
foo.y = 2;
writeln(foo); // prints "Foo(x = 1, y = 2)"
}
---
I tried using getAllMembers, but that also gives me all methods of Foo.
I just want the fields. I also tried FieldTypeTuple
(http://dlang.org/phobos/std_traits.html#FieldTypeTuple) but I get that
gives me the types. And then I can't find anything else in std.traits
that could help me.
Is this possible?
Thanks,
Ary
is there any trait to check if variable is __gshared?
is there any trait to check if variable is __gshared? typeof() for '__gshared int' returns just 'int', whereas for 'shared int' it returns 'shared(int)'. can i check for __gshared storage class somehow?
Re: Problem with taking inout, const references
On Tuesday, 25 March 2014 at 19:20:10 UTC, Uranuz wrote: In this case I don't understand sense of it. Also I have strange feelings about shared, because it's not widely used in code that I'm experienced to see and lacks of good usage examples. shared is used for low-level multithreading, if you're not experienced in it, use safer methods from std.concurrency.
Re: Problem with taking inout, const references
If inout is treated as const does it mean that in this operator I
can't assign new value to cookie object. In this case it means
that I still should make separate class method with the same body
to woraround this. I think that it's a bug. Am I right?
void opIndexAssign(string value, string name)
{ auto cookie = name in this;
if( cookie is null )
_cookies ~= Cookie(name, value);
else
cookie.value = value;
}
Re: Problem with taking inout, const references
Source of error is that I have also the following methods inside
ResponseCookise class:
void opIndexAssign(string value, string name)
{ auto cookie = name in this;
if( cookie is null )
_cookies ~= Cookie(name, value);
else
cookie.value = value;
}
void opIndexAssign( ref Cookie value, string name )
{ auto cookie = name in this;
if( cookie is null )
_cookies ~= value;
else
*cookie = value;
}
In 2.065 I get other error message than in 2.064, but it still
not very informative. Why I get message inside *in* operator but
not in *opIndexAssign*?. And how could I solve this?
/d800/f144.d(49): Error: cannot implicitly convert expression
(&c) of type inout(const(Cookie))* to inout(Cookie)*
/d800/f144.d(38): Error: template instance
f144.ResponseCookies.opBinaryRight!"in" error instantiating
/d800/f144.d(38): Error: rvalue of in expression must be an
associative array, not f144.ResponseCookies
Re: Problem with taking inout, const references
Still compiles for me. Could you please show us a minimal main() as well. Thank you, Ali Yes. This exact piece of code compiles in 2.064, but it doesn't compile in my project. I don't know how to localize the problem yet. It's very strange. I have tried to create class instance with different modifiers (const, inout, immutable), because it could be because of type of array that I try to access. Very strange. I'll try to repeat it.
