Re: Productive vibe.d dev environment (IDE, debugger) on Linux?
On Wednesday, 3 May 2017 at 17:43:07 UTC, kinke wrote: Hey guys, can anyone recommend a more or less production-ready dev environment for vibe.d on Linux? I'm evaluating vibe.d against Phoenix (Elixir/Erlang) for a new project. Today I gave Visual Studio Code a quick shot (with LDC 1.1.1 and DMD 2.071/72/74), with Webfreak's plugins, but I'm not happy at all (gdb/lldb crashing most of the time incl. debugged process, no AutoComplete/IntelliSense due to problems when building some of the plugin dependencies etc.). Any hints are greatly appreciated, as I'm really impressed by vibe.d itself so far. I find MonoDevelop on Linux / Xarmain Studio on Windows with the D language plugin works quite well with Vibe 0.7.30 (OSX is worse but still somewhat useable). Code completion doesn't seem to work well with later versions. I've not tried debugging on Windows but on Linux there is support to use GDB which gives you breakpoints and things inside the IDE. I've not used it beyond breakpoints and inspecting variables I don't know what will work. I've heard that GDC works better with GDB than the other compilers but I've not personally verified that.
Re: Productive vibe.d dev environment (IDE, debugger) on Linux?
On Wednesday, 3 May 2017 at 17:43:07 UTC, kinke wrote: Hey guys, can anyone recommend a more or less production-ready dev environment for vibe.d on Linux? I'm evaluating vibe.d against Phoenix (Elixir/Erlang) for a new project. Today I gave Visual Studio Code a quick shot (with LDC 1.1.1 and DMD 2.071/72/74), with Webfreak's plugins, but I'm not happy at all (gdb/lldb crashing most of the time incl. debugged process, no AutoComplete/IntelliSense due to problems when building some of the plugin dependencies etc.). Any hints are greatly appreciated, as I'm really impressed by vibe.d itself so far. I really just use Atom along with plugins to call build scripts that eventually calls dub for building. Sadly there's still no actual "good" D IDE.
Re: alloca without runtime?
On Thursday, 4 May 2017 at 12:50:02 UTC, Kagamin wrote: You can try ldc and llvm intrinsics http://llvm.org/docs/LangRef.html#alloca-instruction http://llvm.org/docs/LangRef.html#llvm-stacksave-intrinsic Ah, yep! pragma(LDC_alloca) void* alloca(size_t); This appears to work with ldc. It would be nice if there was a way to do this with dmd/other compilers as well though. If it were up to me I'd have alloca defined by the language standard and every compiler would have to provide an implementation like this. At the very least I'd like to have an alloca that works with dmd, as I want to do debug builds with dmd and release builds with ldc.
Re: alias can't find symbol or can't use symbol
On Wednesday, 3 May 2017 at 09:04:07 UTC, Jonathan M Davis wrote: I believe that the core problem is that an alias declaration just aliases a symbol - i.e. it just creates a new name for the symbol. And as far as I can tell, alias n2 = x2.n; is actually equivalent to alias n2 = member.n; You get exactly the same error message if that change is made. It's a bit like how you can call a static function with an object rather than the struct/class(e.g. s.foo() instead of S.foo()). Similarly, if you turn n into a member function, then you get an error like q.d(20): Error: this for n needs to be type member not type outer It's just aliasing the function, not creating a delegate or doing a syntactic conversion. If it _were_ doing a syntactic conversion and just making it so that everywhere you see n2, it got changed to x.n, then I could see code like outer o; o.n2 = 5; working. But that's not how alias declarations work. They just create a new name for the symbol in the scope that they're declared. So, the symbol isn't tied to a particular instance, and you get the problem that you're having. alias this is a bit different, because it isn't really aliasing the symbol - rather it's telling the compiler about an implicit conversion. So, that arguably confuses things a bit, but for your example to work, normal alias declarations would need to do more than create a new name for a symbol, and as I understand it, they don't. Now, I totally agree that it would be nice if your example would work, and I think that I've run into this problem before in my own code, but aliases would have to work a bit differently than they curently do for it to work. It seems like a reasonable enhancement request to me, but I'm not sure what Walter's take on it would be. He has a tendancy to see things how the compiler would in cases like this and not necessarily how a typical programmer would, so it wouldn't surprise me if he's reaction were that of course it wouldn't work, but I don't know. It's often the case that what the programmer thinks is intuitive doesn't really jive with how the language actually works. Thanks, that was enlightening. That said, if alias this really did bring n into the outer scope in the specific case when it's a variable in an embedded struct then `alias n2 = n` in the outer scope would work in the ordinary way. After all, struct fakeOuter { int n; alias n2 = n; } void main() { fakeOuter o; o.n2 = 5; } compiles and runs fine. And presumably as it's a struct being embedded here struct member { int n; } struct outer { member x; alias x this; //alias n2 = n; } the binary layouts of fakeOuter and outer are the same, so the rename is harmless because it has a simple interpretation in regular D without `alias this`.
Re: alloca without runtime?
You can try ldc and llvm intrinsics http://llvm.org/docs/LangRef.html#alloca-instruction http://llvm.org/docs/LangRef.html#llvm-stacksave-intrinsic
Re: alloca without runtime?
On Sunday, 30 April 2017 at 05:07:31 UTC, 岩倉 澪 wrote: I've been playing around with using D with no runtime on Linux, but recently I was thinking it would be nice to have an alloca implementation. I was thinking I could just bump the stack pointer (with alignment considerations) but from what I understand compilers sometimes generate code that references variables relative to RSP instead of RBP? I've seen people saying that a proper alloca can't be implemented without help from the compiler... I took a peek in druntime and found rt.alloca which has __alloca implemented with inline asm. I tried throwing that in my project and calling it but it segfaults on rep movsq. The comments in the code suggest it is trying to copy temps on the stack but I seem to get a really large garbage RCX, I don't fully follow what is going on yet. Is there any way I can get a working alloca without using druntime, c runtime, etc? As a follow-up, here is a simple example of what I mean: first, let's create a main.d, we'll define our own entry point and make a call to alloca in main: extern (C): void _start() { asm nothrow @nogc { naked; xor RBP, RBP; pop RDI; mov RSI, RSP; and RSP, -16; call main; mov RDI, RAX; mov RAX, 60; syscall; ret; } } pragma(startaddress, _start); int main(int argc, char** argv) { import rt.alloca; void* a = __alloca(42); return 0; } Next, let's make an rt directory and copy the source of druntime's rt.alloca into rt/alloca.d Now let's compile these: dmd -betterC -debuglib= -defaultlib= -boundscheck=off -vgc -vtls -c -gc main.d rt/alloca.d Great, now we need to strip symbols out to make this work, like so: objcopy -R '.data.*[0-9]TypeInfo_*' -R '.[cd]tors.*' -R .eh_frame -R minfo -R .group.d_dso -R .data.d_dso_rec -R .text.d_dso_init -R .dtors.d_dso_dtor -R .ctors.d_dso_ctor -N __start_minfo -N __stop_minfo main.o objcopy -R '.data.*[0-9]TypeInfo_*' -R '.[cd]tors.*' -R .eh_frame -R minfo -R .group.d_dso -R .data.d_dso_rec -R .text.d_dso_init -R .dtors.d_dso_dtor -R .ctors.d_dso_ctor -N __start_minfo -N __stop_minfo alloca.o With that out of the way, we are ready to link: ld main.o alloca.o And when we try to run ./a.out we get a segfault. What I want is a way to allocate on the stack (size of allocation not necessarily known at compile-time) and for the compiler to be aware that it can't generate code that refers to variables on the stack relative to rsp, or anything else that might break the naive implementation of alloca as simply bumping rsp with inline asm. Apparently this "magic" __alloca can't be used outside of the compiler, or is there a way to make it work?