Re: @ctfeonly
On Thursday, 7 December 2017 at 05:53:06 UTC, bauss wrote: On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote: As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries - Jonathan M Davis I think that's the point of the attribute. You tell the compiler that this function can only be called at compile-time and any attempt to call it during run-time would be an error. If all you need is a runtime error, you can already put assert(__ctfe); in your function.
Re: mago-mi: GDB/MI compatible frontend for Mago debugger
Unfortunately in this particular case, CDT's debugging is pretty fancy and is going to need most if not all of the MI. On Thursday, 19 May 2016 at 13:29:14 UTC, Bruno Medeiros wrote: On 19/05/2016 08:41, Vadim Lopatin wrote: On Wednesday, 18 May 2016 at 18:02:12 UTC, Bruno Medeiros wrote: While DDT technically work oks with GDB (the GDB from mingw-w64 that is), you are right, there isn't a compiler on Windows that supplies debug info in the way GDB understands. See https://wiki.dlang.org/Debuggers. DMD produces debug info COFF or OMF format, which GDB doesn't know anything about (nor ever will). LDC should in theory work with DWARF info, but this is broken somehow. Not because of LLVM though, since for example Rust on Windows works. As for GDC, it doesn't even supply binaries for Windows (that target Windows) - it is not a supported platform. BTW, Eclipse/DDT should in theory work with mago-mi as well, at least if the protocol is implemented correctly. Have you tried it? I dunno how complete your MI implementation is. So it looks like mago-mi might be helpful for DDT on Windows. mago-mi supports subset of GDB/MI commands enough for DlangIDE, but it can be easy extended. Currenlty supported commands can be shown using help command (use --interpreter=mi2 when running mago-mi, otherwise it will print non-MI commands). Also commands are listed in readme file https://github.com/buggins/mago/blob/master/MagoMI/mago-mi/README.md I didn't try DDT with mago-mi, and so I'm not sure which commands must be supported by debugger to get it working with DDT. To get list of commands DDT tries to use you can either add --log-file=magomi.log --log-level=TRACE to mago-mi command line or use debug build of mago-mi. It will all STDIN data to log file, and report errors for unsupported commands. I also don't know which MI commands need to be supported to have it work with DDT. The thing is I didn't write the GDB debugger integration for DDT, I just reused the one from CDT. So I'm not that familiar with those internals. BTW, the MI integration is fairly language agnostic, so in theory your debugger could be used by CDT to debug C/C++ programs too, no? At least those generated by DMC. Maybe Visual Studio ones too? I'm experimenting with the build of mago-mi that comes with the current ~master for dlangide, and it seems to throw an unrecognized parameter error when on the --log-level=TRACE parameter. And it seems that the version string it returns upsets eclipse, as it throws the following error: Could not determine GDB version using command: D:\WinHome\\AppData\Roaming\dub\packages\dlangide-master\bin\mago-mi.exe --version Unexpected output format: mago-mi debugger v0.1 Though, from my experience using it in Linux, eclipse-CDT's debugger seems pretty full-featured; it will likely require large swaths of mi functionality to be fully useful.
Re: DDT 1.0.0 released.
On Tuesday, 17 May 2016 at 14:04:04 UTC, Bruno Medeiros wrote: New DDT release out: dfmt support, performance improvements to semantic operations, more build command customization, fixes. Please see changelog for full list: https://github.com/DDT-IDE/DDT/releases/tag/v1.0.0 Since DDT has generally been quite stable, and since the current release is very close to the end-game vision I had for a D IDE - at least as far as my free time would allow to create - I've decided to version this as 1.0. I've been working for nearly 8 years on this project after all (with some intermission periods), so I guess 1.0 was a bit due... O.o' I expect it will mainly be small updates from now on, not any major new features (other than perhaps DCD support). Is there any chance we'll be able to get an outline view in the project explorer a la CDT?
is __traits(allMembers) usable in a non-deprecated way?
__traits(allMembers, ) has always been pretty much essential to any non-trivial struct, class, or module-based introspection, but given the visibility rules changes in 2.071.0, it looks like it's not even allowed to check whether a given symbol is public. (i.e. with __traits(getProtection, Type, member)) Is there a new, approved way of doing this?
Trouble complinig DMD 2.070 on windows
I'm trying to compile a 64-bit DMD.exe on windows (as my project has enough CTFE and Template work that it bumps up against the 4gb limit). with the pre-DDMD setup I was just able to load the thing up in visual studio 2013 and build, but I've been having some difficulty with 2.070's projects. Namely, it seems that no matter what type of bulid I do, I get a bunch of errors in elfobj.c and one in filename.d Error 1 error C3861: 'assert': identifier not found D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3512 1 dmd_backend Error 2 error C3861: 'assert': identifier not found D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3527 1 dmd_backend Error 3 error C2352: 'Obj::reftoident' : illegal call of non-static member function D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3528 1 dmd_backend Error 4 error C2065: 'symtab_strings' : undeclared identifier D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3531 1 dmd_backend Error 5 error C2227: left of '->size' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3531 1 dmd_backend Error 6 error C2065: 'symtab_strings' : undeclared identifier D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3532 1 dmd_backend Error 7 error C2227: left of '->writeString' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3532 1 dmd_backend Error 8 error C2065: 'symtab_strings' : undeclared identifier D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3533 1 dmd_backend Error 9 error C2227: left of '->setsize' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3533 1 dmd_backend Error 10 error C2227: left of '->size' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3533 1 dmd_backend Error 11 error C2065: 'symtab_strings' : undeclared identifier D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3534 1 dmd_backend Error 12 error C2227: left of '->writeString' must point to class/struct/union/generic type D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3534 1 dmd_backend Error 13 error C3861: 'elf_addsym': identifier not found D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3536 1 dmd_backend Error 14 error C3861: 'MAP_SEG2SECIDX': identifier not found D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3536 1 dmd_backend Error 15 error C2352: 'Obj::reftoident' : illegal call of non-static member function D:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3542 1 dmd_backend Error 16 Error: function ddmd.root.filename.GetFullPathNameA (const(wchar)* lpFileName, uint nBufferLength, wchar* lpBuffer, wchar** lpFilePart) is not callable using argument types (const(char)*, int, typeof(null), typeof(null)) D:\programs\dmd\dmd2\src\dmd\root\filename.d 645 17 IntelliSense: identifier "assert" is undefined d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3512 5 dmd_backend 18 IntelliSense: a nonstatic member reference must be relative to a specific object d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3528 13 dmd_backend 19 IntelliSense: identifier "symtab_strings" is undefined d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3531 29 dmd_backend 20 IntelliSense: identifier "elf_addsym" is undefined d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3536 30 dmd_backend 21 IntelliSense: identifier "MAP_SEG2SECIDX" is undefined d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3536 79 dmd_backend 22 IntelliSense: a nonstatic member reference must be relative to a specific object d:\Programs\dmd\dmd2\src\dmd\backend\elfobj.c 3542 9 dmd_backend (If this is an actual issue with the code or projects I'll file a bug, but I wanted to make sure it wasn't just me doing something wrong first)
Re: Trouble complinig DMD 2.070 on windows
I'm building master with VS2015, but you need to make sure you manually update to the latest VisualD release (but that problem is nothing to do with the errors you show here). Consider updating to 2015? It is the first really significant improvement to MS's stack for like a decade (major C++/standards improvements). At this point, I think it is in all windows developers best interest to purge and forget the rancid memory of every prior VS release ;) Just to be clear, all I have VS for is compiling DMD; I don't actually use it to develop. Should I still update?
Re: String Metaprogramming
On Saturday, 18 July 2015 at 13:48:20 UTC, Clayton wrote:
Am new to D programming, am considering it since it supports
compile-time function execution . My challenge is how can I
re-implement the function below so that it is fully executed in
compile-time. The function should result to tabel1 being
computed at compile-time. There seems to be a lot of mutation
happening here yet I have heard no mutation should take place
in meta-programming as it subscribes to functional programming
paradigm.
void computeAtCompileTime( ref string pattern ,ref int[char]
tabel1){
int size = to!int(pattern.length) ;
foreach( c; ALPHABET){
tabel1[c] = size;
}
for( int i=0;isize -1 ; ++i){ //Initialise array
tabel1[pattern[i]] = size -i-1;
pragma(msg, format(reached pattern
table1[pattern[i]]=(%s) here,
table1[pattern[i]].stringof ~ v=~ (size
-i-1).stringof));
}
}
Actually, the main things you can't do in CTFE are FPU math
operations (much of std.math has issues unfortunately), compiler
intrinsics, pointer/union operations, and I/O. I don't
immediately see anything that will cause issues with CTFE in that
function. However, sometimes the compiler isn't smart enough to
figure out that it should be doing that, but you can force the
compiler to try CTFE using this pattern
int ctfeFunc() {
}
void main() {
enum val = ctfeFunc();
}
enums are manifest constants, and thus must be computable at
compile time, so this will issue an error if something in your
function can't CTFE.
Re: std.concurrency: The fate of unmatched messages
On Saturday, 11 July 2015 at 02:15:02 UTC, ketmar wrote: so simply don't receive the messages you don't need right now. as i said, `receive()` doesn't look to top message only, it scans the whole mailbox, trying to find a message that matches. you can use `receiveTimeout()` to do nothing if there are no suitable messages. you can also adjust mailbox size and mode. Okay, so it doesn't purge unrecognized messages, then! That's what I needed to know!
Re: std.concurrency: The fate of unmatched messages
On Friday, 10 July 2015 at 23:39:30 UTC, ketmar wrote: this way your `receive` will get all messages. simply do nothing in `Variant` handler to drop messages you don't want to process. [1] http://dlang.org/phobos/std_concurrency.html#.receive The thing is, I want to do receive() in two separate places, and I want each receive() call to leave the other's messages alone, not drop them.
std.concurrency: The fate of unmatched messages
I'm putting together a program that uses std.concurrency to handle two child threads from the main thread; The kicker here is that both the children do very different things. And I would like to handle receive() calls for them in separate locations. But from what I can tell, each thread has only one mailbox. And none of the documentation i can find for std.concurrency mentions what happens when one receive() call gets a message it doesn't understand. Are unmatched messages left in the Mailbox, or are they discarded? (I am admittedly strongly hoping it is the former) And if the latter, is there any way to actually give a single thread multiple mailboxes?
Re: What have you done with UDAs?
On Monday, 22 June 2015 at 19:09:40 UTC, weaselcat wrote: I never seem to use them for anything, has anyone else done anything interesting with them? I use UDAs in my project to generate GTK UI for editing components in my ECS. (For things like marking string fields as filenames, or giving numeric fields upper and lower bounds) https://dl.dropboxusercontent.com/u/187059/Screenshot-sarah%20-%20Entity%20Editor.png
Feasibility of a std.encoding.safeDecode overload for InputRanges?
Currently, std.encoding.safeDecode seems to only work on Random Access Ranges that have a .length property. (So essentially arrays and array-like objects), but I would very much like to be able to safeDecode strings that have lazy range-based processing applied to them (which often ends up with only an InputRange). Given that throwing-decodes work just fine on input ranges, would it be possible to let safe decodes work for them as well?
64-bit DMD .exe for windows?
I've got a project that, due to extensive use of LuaD conversions, templates with a lot of parameters, and CTFE, has managed to require 4gb of ram to compile. Which means that, for the moment, I can't build on windows as the dmd compiler is a 32-bit executable and throws an out of memory error. Is there any chance that we could publish a win64 build of dmd.exe?
Re: Why .dup not work with multidimensional arrays?
It's because arrays are references types, and .dup is a strictly
shallow copy, so you're getting two outer arrays that reference
the same set of inner arrays. You'll have to duplicated each of
the inner arrays yourself if you need to make a deep copy.
On Friday, 8 May 2015 at 02:15:38 UTC, Dennis Ritchie wrote:
Hi,
Should the method .dup work with multidimensional arrays for
copying?
-
import std.stdio;
void main() {
auto a = [1, 2, 3];
auto b = a.dup;
b[] *= 2;
writeln(a = , a); // [1, 2, 3] // OK
writeln(b = , b); // [2, 4, 6] // OK
auto c = [[[1, 2, 3], [4, 5, 6, 7, 8]],
[[9, 10], [11, 12, 13]]];
auto d = c.dup;
writeln(d[0][1][1 .. $ - 1] = ,
d[0][1][1 .. $ - 1]);
d[0][1][1 .. $ - 1] *= 3;
writeln(c = , c);
// [[[1, 2, 3], [4, 15, 18, 21, 8]],
// [[9, 10], [11, 12, 13]]] // wrong
writeln(d = , d);
// [[[1, 2, 3], [4, 15, 18, 21, 8]],
// [[9, 10], [11, 12, 13]]] // OK
}
-
http://ideone.com/Ddtm47
I thought the slice of the array c[0][1][1 .. $ - 1] = [5, 6,
7] not had to change to [15, 18, 21] by multiplying by 3.
Re: LDC 0.15.0 alpha1 released! Please help test!
I notice that there's no mingw based windows version with his release. Does this msvc based build output gdb-compatible debugging symbols?
Working around the 64k global types issue on windows
I've got a program that, likely through a combination of use of GtkD and several variadic templates, has managed to bump its head against the 64K global types limitation in the Windows version of DMD. And unfortunately, neither GDC or LDC's current windows versions work well enough to compile my code, so at the moment I'm in a spot where I literally can't debug on windows. (And the program compiles and runs fine when I turn off adding debug symbols, and also compiles with debug symbols on linux, so I'm pretty sure I'm not doing anything grievously wrong) Is there any way to work around this issue on windows? Override the limit, somehow get the compiler to mangle template instantiations in a less verbose way?
