Re: Phobos func for string -> enum member?
On 10/13/2016 07:14 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Thu, Oct 13, 2016 at 07:11:15PM -0400, Nick Sabalausky via
Digitalmars-d-learn wrote:
I'm sure it'd be easy enough to write, but does phobos have a simple
way to convert the name of an enum member from a runtime string to the
enum type?
Ie, something like:
enum Foobar { foo=1, bar }
Foobar a = doesThisExistInPhobos!Foobar("foo");
I'm not finding anything like it in the docs, but I'm wondering if I
just missed it somewhere.
import std.conv : to;
Foobar a = "foo".to!Foobar;
:-)
T
Ah. Right. ;)
Thanks all.
Re: Phobos func for string -> enum member?
On Thu, Oct 13, 2016 at 07:11:15PM -0400, Nick Sabalausky via
Digitalmars-d-learn wrote:
> I'm sure it'd be easy enough to write, but does phobos have a simple
> way to convert the name of an enum member from a runtime string to the
> enum type?
>
> Ie, something like:
>
> enum Foobar { foo=1, bar }
> Foobar a = doesThisExistInPhobos!Foobar("foo");
>
> I'm not finding anything like it in the docs, but I'm wondering if I
> just missed it somewhere.
import std.conv : to;
Foobar a = "foo".to!Foobar;
:-)
T
--
It is impossible to make anything foolproof because fools are so ingenious. --
Sammy
Re: Phobos func for string -> enum member?
On 10/13/2016 04:11 PM, Nick Sabalausky wrote:
I'm sure it'd be easy enough to write, but does phobos have a simple way
to convert the name of an enum member from a runtime string to the enum
type?
Ie, something like:
enum Foobar { foo=1, bar }
Foobar a = doesThisExistInPhobos!Foobar("foo");
I'm not finding anything like it in the docs, but I'm wondering if I
just missed it somewhere.
import std.conv;
enum Foobar { foo=1, bar }
void main() {
assert("foo".to!Foobar == Foobar.foo);
}
Ali
Phobos func for string -> enum member?
I'm sure it'd be easy enough to write, but does phobos have a simple way
to convert the name of an enum member from a runtime string to the enum
type?
Ie, something like:
enum Foobar { foo=1, bar }
Foobar a = doesThisExistInPhobos!Foobar("foo");
I'm not finding anything like it in the docs, but I'm wondering if I
just missed it somewhere.
Re: Building DMD with DMD or LDC
On Thursday, 13 October 2016 at 19:28:11 UTC, Daniel Kozak wrote: You can easy try it. Just build dmd with dmd, than with ldc. And then try to compile DMD frontend with both dmd versions :) Dne 13.10.2016 v 21:07 Nordlöw via Digitalmars-d-learn napsal(a): Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC? When I replace dmd with ldmd2 in the last call of the build it crashes as CC=c++ ldmd2 -ofdmd -m64 -vtls -J. -J../res -L-lstdc++ -version=MARS -wi -O -release -inline access.d aggregate.d aliasthis.d apply.d argtypes.d arrayop.d arraytypes.d attrib.d builtin.d canthrow.d clone.d complex.d cond.d constfold.d cppmangle.d ctfeexpr.d dcast.d dclass.d declaration.d delegatize.d denum.d dimport.d dinifile.d dinterpret.d dmacro.d dmangle.d dmodule.d doc.d dscope.d dstruct.d dsymbol.d dtemplate.d dversion.d entity.d errors.d escape.d expression.d func.d globals.d hdrgen.d id.d identifier.d impcnvtab.d imphint.d init.d inline.d intrange.d json.d lexer.d lib.d link.d mars.d mtype.d nogc.d nspace.d opover.d optimize.d parse.d sapply.d sideeffect.d statement.d staticassert.d target.d tokens.d traits.d utf.d visitor.d typinf.d utils.d statementsem.d safe.d objc_stubs.d libelf.d scanelf.d irstate.d toelfdebug.d toctype.d glue.d gluelayer.d todt.d tocsym.d toir.d dmsc.d tocvdebug.d backend/bcomplex.d backend/cc.d backend/cdef.d backend/cgcv.d backend/code.d backend/cv4.d backend/dt.d backend/el.d backend/global.d backend/obj.d backend/oper.d backend/outbuf.d backend/rtlsym.d backend/ty.d backend/type.d tk/dlist.d root/aav.d root/array.d root/ctfloat.d root/file.d root/filename.d root/man.d root/outbuffer.d root/port.d root/response.d root/rmem.d root/rootobject.d root/speller.d root/stringtable.d newdelete.o glue.a backend.a tk/dlist.d(51): list_inited is thread local backend/cgcv.d(26): ftdbname is thread local 0 ldc20x013af6a5 1 ldc20x013ae05e 2 ldc20x013ae19a 3 libpthread.so.0 0x7f3ce59443d0 4 ldc20x012fcd94 5 ldc20x01350a42 6 ldc20x013532fd 7 ldc20x01315d2a 8 ldc20x01315e0e 9 ldc20x01315f24 10 ldc20x006cb40b 11 ldc20x006e1c77 12 ldc20x006daf86 13 ldc20x00686488 14 ldc20x0058a1c9 15 ldc20x0068847b 16 ldc20x013e2fff _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 15 17 ldc20x013e2fc4 18 ldc20x013e2eed 19 libc.so.6 0x7f3ce506a830 __libc_start_main + 240 20 ldc20x0049c751 Error: Error executing /home/per/.local/ldc2-1.1.0-beta3-linux-x86_64/bin/ldc2: Segmentation fault (core dumped) I'm using LDC 1.1.0-beta3 on Ubuntu 16.04.
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Thursday, 13 October 2016 at 19:11:36 UTC, Adam D. Ruppe wrote: Try `-defaultlib=libphobos2.so` with your dmd command line. The .so version is pic compiled. Building DMD fails to how do I modify the call make -f posix.mak under the dmd checkout?
Re: ReturnType and Parameters of Templated function/method
On Thursday, 13 October 2016 at 21:07:17 UTC, ketmar wrote: On Thursday, 13 October 2016 at 20:52:09 UTC, Patric Dexheimer wrote: So for now my idea is to brute force the numbers of arguments with 'compiles' trait or trying to get the sourcecode somehow. depending on source code form (even if you can get it) is highly error-prone. consider it UB. also, i think that you'd better not guess, but ask the user to explicitly instantiate the methods with `alias` -- this way you have to write less hacky code, and the user will have more control over what is bound. you may provide helper mixin templates to instantiate n-ary functions with given set of types too. this is slightly more work on the user side, but it doesn't depend on hacks and undocumented things. Yes, but i like the idea of "automagically" bind everything with little user effort. Sometimes you have a lot of code to expose to lua (and templated code as well with lots of templated argument combinations), so I think is nice to have some automated work on this. But you are right about the "highly error-prone" part. I´ll try to avoid that path :)
Re: ReturnType and Parameters of Templated function/method
On Thursday, 13 October 2016 at 20:52:09 UTC, Patric Dexheimer wrote: So for now my idea is to brute force the numbers of arguments with 'compiles' trait or trying to get the sourcecode somehow. depending on source code form (even if you can get it) is highly error-prone. consider it UB. also, i think that you'd better not guess, but ask the user to explicitly instantiate the methods with `alias` -- this way you have to write less hacky code, and the user will have more control over what is bound. you may provide helper mixin templates to instantiate n-ary functions with given set of types too. this is slightly more work on the user side, but it doesn't depend on hacks and undocumented things.
Re: Illegal behaviour or GDC bug?
On Thursday, 13 October 2016 at 20:22:51 UTC, Peter Campbell wrote: OK that's cool, I'll just avoid GDC for now. Is it generally a good approach to assume if something compiles in DMD then it's correct and just hope that GDC/LDC pick up the latest version at some point? mostly yes. btw, ldc has devbuilds available from it's github page, those are usually on par with current dmd. it is very sad that gdc has so little manpower, tho. Iain doing a great job, but...
Re: ReturnType and Parameters of Templated function/method
On Thursday, 13 October 2016 at 18:01:25 UTC, Ali Çehreli wrote:
On 10/13/2016 07:19 AM, Patric Dexheimer wrote:
There is a way to capture the return type/parameters of a
templated
function like:
void add(T)(T t){}
Parameters!add;
Yes, i know that the template don´t have any type until
explicitly coded
like:
Parameters!(add!int);
Or another solution like getting the string function
declaration will be
enough:
"void add(T)(T t)"
Like what happens with:
void other_add(int x){}
writeln( typeof(__traits(getMember, Module,
"other_add")).stringof );
//output: void(int x)
There are several related options in std.traits. What exactly
are you trying to achieve? Perhaps there is a better way.
Ali
I´m working on a Lua binding for D.
One of my ideas is to try to make automatic binding for structs,
even if some method have templated arguments. My idea is to at
least try to bind templated functions with basic types
automatically (in the example, bind then add!int, add!float,
add!string etc..)
I tried arity!add which should resolve my problem too, but did´nt
compile too.
So for now my idea is to brute force the numbers of arguments
with 'compiles' trait or trying to get the sourcecode somehow.
Batch compilation and -unittest flag
Is there a way to call dmd/rdmd on a set of files but only
activate unittest for one of them?
This would significantly cut down my wait times when developing D
in Emacs with flycheck-d-unittest:
https://github.com/flycheck/flycheck-d-unittest
Without it I have to implement my own build logic:
1. dmd -c -unittest -main
2. dmd -c -unittest -main
3. ld.gold -o test top.o sub1.o sub2.o ... subN.d
when top.d depends (either directly or transitively) on
sub{1,...,N}.d
Further, building 1. and 2. separately wastes CPU-cycles through
duplicate parsing of sub{1,...,N}.d.
Re: Illegal behaviour or GDC bug?
On Thursday, 13 October 2016 at 20:18:31 UTC, ketmar wrote: sadly, gdc has way older frontend version than ldc (and dmd, of course). gdc is like 2.067, and ldc/dmd is 2.072. that this was fixed in later versions, but gdc is not updated yet. OK that's cool, I'll just avoid GDC for now. Is it generally a good approach to assume if something compiles in DMD then it's correct and just hope that GDC/LDC pick up the latest version at some point?
Re: Illegal behaviour or GDC bug?
sadly, gdc has way older frontend version than ldc (and dmd, of course). gdc is like 2.067, and ldc/dmd is 2.072. that this was fixed in later versions, but gdc is not updated yet.
Illegal behaviour or GDC bug?
Good evening all, I'm just starting to learn D and I've been experimenting with some template stuff as well as checking out DMD, GDC and LDC. During my experimentation I found a piece of code that doesn't compile in GDC but does compile in DMD and LDC. The code snippet can be found here: http://dpaste.com/1BCVKSW Basically it's a 3D vector with some enums that reference the structure itself. In GDC produces the following errors: Line 9: error: cannot create a struct until its size is determined Line 19: error: template instance Vector3.Vector3T!float error instantiating I've seen this error in C++ before and I believe it's illegal behaviour in C++ land. In regard to D, both DMD and LDC seem to believe it's legal syntax and allow me to use it without problems. Have I found a bug with GDC or should I not be able to do this?
Re: Building DMD with DMD or LDC
You can easy try it. Just build dmd with dmd, than with ldc. And then try to compile DMD frontend with both dmd versions :) Dne 13.10.2016 v 21:07 Nordlöw via Digitalmars-d-learn napsal(a): Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC?
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
Try `-defaultlib=libphobos2.so` with your dmd command line. The .so version is pic compiled. Or you can recompile the whole lib.
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Thursday, 13 October 2016 at 18:35:43 UTC, Matthias Klumpp wrote: The new toolchains of Ubuntu (and Debian soon too) default to PIE code, so in order to link correctly, the project needs to be compiled with PIE/PIC to work. So how do I do this? Instructions? Can I bootstrap DMD or do I need to cross-compile to the new PIE/PIC?
Building DMD with DMD or LDC
Is there a large speed difference in compilation time depending on whether the DMD used is built using DMD or LDC?
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Thursday, 13 October 2016 at 19:01:55 UTC, Nordlöw wrote: Can I bootstrap DMD or do I need to cross-compile to the new PIE/PIC? Is this what AUTO_BOOTSTRAP=1 is for and what does it do?
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Thursday, 13 October 2016 at 17:07:19 UTC, Nordlöw wrote: On Thursday, 13 October 2016 at 17:02:32 UTC, Nordlöw wrote: Am I using the wrong GCC version? Should I use GCC 5 instead? GCC 6.2 is default on 16.10. Compiling DMD with GCC 5 as make -f posix.mak HOST_CXX=g++-5 also fails with same errors. The new toolchains of Ubuntu (and Debian soon too) default to PIE code, so in order to link correctly, the project needs to be compiled with PIE/PIC to work.
Re: ReturnType and Parameters of Templated function/method
On 10/13/2016 07:19 AM, Patric Dexheimer wrote:
There is a way to capture the return type/parameters of a templated
function like:
void add(T)(T t){}
Parameters!add;
Yes, i know that the template don´t have any type until explicitly coded
like:
Parameters!(add!int);
Or another solution like getting the string function declaration will be
enough:
"void add(T)(T t)"
Like what happens with:
void other_add(int x){}
writeln( typeof(__traits(getMember, Module, "other_add")).stringof );
//output: void(int x)
There are several related options in std.traits. What exactly are you
trying to achieve? Perhaps there is a better way.
Ali
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Thursday, 13 October 2016 at 17:02:32 UTC, Nordlöw wrote: Am I using the wrong GCC version? Should I use GCC 5 instead? GCC 6.2 is default on 16.10. Compiling DMD with GCC 5 as make -f posix.mak HOST_CXX=g++-5 also fails with same errors.
Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
I just upgraded my Ubuntu to 16.10 and now my rebuilding of dmd from git master fails as /usr/bin/ld: idgen.o: relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(object_a_66e.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC What's wrong? Am I using the wrong GCC version? Should I use GCC 5 instead? GCC 6.2 is default on 16.10.
Re: Rust-like collect in D
On Thursday, 13 October 2016 at 10:00:56 UTC, Nordlöw wrote: For instance, we can use `if (!isInfinite!Range)` to forbid collecting values from an infinite `Range`. Is this checking done? That is `0.iota.make!Array` should not be allowed. https://github.com/dlang/phobos/pull/4860
Re: Current State of the GC?
On Thursday, 13 October 2016 at 11:55:50 UTC, Jonathan M Davis wrote: On Monday, October 10, 2016 21:12:42 Martin Lundgren via Digitalmars-d-learn wrote: I've been reading up a bit on the D garbage collector. Seen mostly negative things about it. I've also seen a lot of proposals and what not, but not much about the current state of things. [...] We should put this whole reply as FAQ on website :) Andrea
ReturnType and Parameters of Templated function/method
There is a way to capture the return type/parameters of a
templated function like:
void add(T)(T t){}
Parameters!add;
Yes, i know that the template don´t have any type until
explicitly coded like:
Parameters!(add!int);
Or another solution like getting the string function declaration
will be enough:
"void add(T)(T t)"
Like what happens with:
void other_add(int x){}
writeln( typeof(__traits(getMember, Module,
"other_add")).stringof ); //output: void(int x)
Re: Current State of the GC?
On Monday, October 10, 2016 21:12:42 Martin Lundgren via Digitalmars-d-learn wrote: > I've been reading up a bit on the D garbage collector. Seen > mostly negative things about it. I've also seen a lot of > proposals and what not, but not much about the current state of > things. > > The latest page I can find about it is 2015H1. It mentions > improving the GC and making libraries less reliant on it. > However, I can't find *any* information about what GC > improvements have been made. No up to date performance > comparisons, etc. > > So what's been happening in memory management land lately? Bad GC > seems like one of the Dlangs weak points, so showing improvements > here could definitely bring more people in. The GC has had various improvements made to it over the last couple of years, but the folks doing it haven't really be advertising what they've been up to, so without digging through the commit logs and figuring out what they did, I can't tell you what the improvements are. Martin Nowak _was_ going to do a talk on some of that at dconf 2015, but he missed his flight, and the talk never happened. Improvements towards marking stuff @nogc where appropriate in druntime and Phobos are slowly coming along, but there's still plenty of work to do there. There's also been a fair bit of work towards taking functions that result in strings and creating alternate versions which result in lazy ranges so that they don't have to allocate. std.experimental.allocator is in place now, paving the way for a lot of stuff not using the GC. There are all kinds of small things being done, incrementally moving towards not using the GC when it's not actually required to do what the function is doing. But some classes of things are always going to use the GC. And some stuff will need some language improvements in order to not need the GC (e.g. exceptions pretty much require the GC as it stands; it's possible to use them without the GC but incredibly unsafe, because there is no standard mechanism in place for handling their memory other than the GC; the result is that pretty much anything using exceptions right now can't be @nogc even if it doesn't use the GC for anything but exceptions). Because it was determined that stuff like std.typecons.RefCounted can't actually be done in an @safe manner, Walter has done some work towards adding @safe refererence counting to the language for the cases where that makes more sense than the GC (and that may or may not help fix the problem with requiring the GC for exceptions). But in order to do that, he's been doing a lot of work towards improving @safe in general, and who knows when the ref-counting stuff will actually arrive. So, various improvements have been made and continue to be made which improve the GC, or reduce the need for the GC (or simply reduce the need for heap allocation in general), or which provide alternatives to using the GC. But there's still plenty to be done. It's also possible to completely disable use of the GC in D, but you lose out on a few features (and while the std lib doesn't use the GC heavily, it does use it, so if you remove the GC from the runtime, you can't use Phobos), so it's not particularly advisable. But you can get a _long_ way just by being smart about your GC use. A number of D programmers have managed to use D with full use of the GC in high performance code simply by doing stuff like make sure that a collection cycle doesn't kick in in hot spots in the program (e.g. by calling GC.disable when entering the hot spot and then GC.enable when leaving), and for programs that need to do real-time stuff that can't afford to have a particular thread be stopped by a GC collection, you just use a thread that's not managed by the GC for that critical thread, and it's able to keep going even if the rest of the program is temporarily stopped by a collection. The reality of the matter though is that for the most part, the problem with the GC and D is primarily a PR issue and not a practical one. A lot of folks from C/C++ land freak out when they see that a GC is being used and just assume that there are major efficiency problems. It _is_ true that if you allocate stuff on the heap heavily and churn through objects such that you keep getting the garbage collector to kick in, it's going to hurt the performance of your program, but so is lots of allocating and deallocating of heap objects in general, even if a GC isn't involved at all. But idiomatic D doesn't use the heap anywhere near as much as many languages tend to (e.g. structs on the stack are used much more heavily than classes on the heap and lazy ranges are a huge win at avoiding a lot of heap allocations; and while dynamic arrays do normally use the GC heap, the fact that they can be sliced instead of having to be copied is a huge performance win). So, while you _can_ get yourself in trouble with the GC, the vast majority of programs really have no problem with it at all. And certain classes
