Re: Function in a slice instead of just pointer?
On Thursday, 21 June 2018 at 21:00:46 UTC, Michael Brown wrote: Hi D Community, Is it possible to get a slice of a function, rather than just its start pointer? No. I'm interested in currying a function at runtime - So I would need to copy a function block (Either the original function, a wrapper function, or copys of manually altered functions). see https://dlang.org/phobos/std_functional.html#partial Addresses of labels would also be useful - Does Dlang have computable labels? (&&lbl in C) Don't think so. I suspect Ill have to do this in ASM, but seeing if there's a higher level solution? Kind Regards, Mike Brown
Function in a slice instead of just pointer?
Hi D Community, Is it possible to get a slice of a function, rather than just its start pointer? I'm interested in currying a function at runtime - So I would need to copy a function block (Either the original function, a wrapper function, or copys of manually altered functions). Addresses of labels would also be useful - Does Dlang have computable labels? (&&lbl in C) I suspect Ill have to do this in ASM, but seeing if there's a higher level solution? Kind Regards, Mike Brown
Re: Move and CTFE
On Thursday, 21 June 2018 at 20:15:42 UTC, Stefan Koch wrote: To give some more context here: CTFE is the most well tested feature in dmd. So there is no room for sloppiness or functional differences! As you previously mentioned the newCTFE engine works on a completely different basis then the old engine does. This does provide both speed and better debugging support, but comes at the cost of having to re-implement a complete backend and some parts of semantic analysis. Keep up the great work!
Re: Move and CTFE
On Wednesday, 30 May 2018 at 23:07:26 UTC, Jonathan M Davis wrote: newCTFE is taking a very different approach to CTFE, and in theory, it will fix many of the problems that CTFE currently has, but it's taking Stefan quite a while to get it to where it needs to be to actually merge it. To give some more context here: I do intend newCTFE to be a drop-in replacement that offers the same functionality (including the very accurate error detection and precise error reporting) Which was quite hard to achieve due to not being able of creating Error-Nodes from inside the interpreter. I'd say for the amount of things that newCTFE currently _correctly_ handles it has been fast progress! CTFE is the most well tested feature in dmd. So there is no room for sloppiness or functional differences! As you previously mentioned the newCTFE engine works on a completely different basis then the old engine does. This does provide both speed and better debugging support, but comes at the cost of having to re-implement a complete backend and some parts of semantic analysis.
Re: Convert path to file system path on windows
On Thursday, 21 June 2018 at 18:46:05 UTC, Dr.No wrote:
How can I do that with D?
In C# you can do that:
var filename = @"C:\path\to\my\file.txt";
var file = new Uri(filename).AbsoluteUri;
// file is "file:///C:/path/to/my/file.txt"
How can I do that in D?
import std.stdio;
import std.exception;
import core.sys.windows.windows;
import std.windows.syserror;
@safe void henforce(HRESULT hres, lazy string msg = null, string
file = __FILE__, size_t line = __LINE__)
{
if (hres != S_OK)
throw new WindowsException(hres, msg, file, line);
}
@trusted wstring absoluteUri(string path)
{
import std.path : absolutePath;
import std.utf : toUTF16z;
import core.sys.windows.shlwapi;
import core.sys.windows.wininet;
auto shlwapi = wenforce(LoadLibraryA("Shlwapi"), "Failed to
load shlwapi");
enforce(shlwapi !is null);
auto urlCreateFromPath =
cast(typeof(&UrlCreateFromPathW))wenforce(shlwapi.GetProcAddress("UrlCreateFromPathW"), "Failed to find UrlCreateFromPathW");
scope(exit) FreeLibrary(shlwapi);
wchar[INTERNET_MAX_URL_LENGTH] buf;
auto size = cast(DWORD)buf.length;
henforce(urlCreateFromPath(path.absolutePath.toUTF16z,
buf.ptr, &size, 0));
return buf[0..size].idup;
}
int main(string[] args)
{
foreach(path; args)
{
writeln(absoluteUri(path));
}
return 0;
}
Re: Convert path to file system path on windows
On Thursday, 21 June 2018 at 18:46:05 UTC, Dr.No wrote: How can I do that with D? In C# you can do that: var filename = @"C:\path\to\my\file.txt"; var file = new Uri(filename).AbsoluteUri; // file is "file:///C:/path/to/my/file.txt" How can I do that in D? I don't know of a specific implementation that does the same, but I can point you to some spots you might look into: std.path: https://dlang.org/phobos/std_path.html std.uri: https://dlang.org/phobos/std_uri.html vibe.inet.url: http://vibed.org/api/vibe.inet.url/URL vibe.core.path: http://vibed.org/api/vibe.core.path/ I really feel like vibed's documentation api site is missing some nice examples of usage to get a quick feel of the provided api.
Re: What is the point of nothrow?
On Thursday, June 21, 2018 13:16:28 wjoe via Digitalmars-d-learn wrote: > On Wednesday, 20 June 2018 at 12:22:33 UTC, Kagamin wrote: > > Do you know how to extract information from it on an unfamiliar > > OS? Reading stack trace is easier and self-evident. > > Counter question: How do you develop for an unfamiliar OS with > unfamiliar tools in the first place ? > The concept of a debugger and a memory dump is fundamentally the > same on every OS I know or care about just as much as the D error > implementation doesn't care about niche cases. > > Of course you can debug your applications via print to console if > you feel that this is productive enough and ignore the bugs you > can't fix that way. Simply having a stack trace would be plenty in many cases, and if you're primarily developing an a different OS from the one the user was on when the error occurred, getting a stack trace may allow you to see what the problem is and fix it without setting up a debugger on the OS that the user was running (which could be a huge timesaver if you don't normally use that OS). That being said, the optimal solution is likely printing out the error message and stack trace, and then giving a coredump (or the OS' equivalent) at the point of the failure. Then if the message and stack trace are enough, you're good to go, and if you need the coredump to get more detailed information, then you have it. - Jonathan M Davis
Convert path to file system path on windows
How can I do that with D? In C# you can do that: var filename = @"C:\path\to\my\file.txt"; var file = new Uri(filename).AbsoluteUri; // file is "file:///C:/path/to/my/file.txt" How can I do that in D?
Re: What is the point of nothrow?
On Wednesday, 20 June 2018 at 12:22:33 UTC, Kagamin wrote: On Tuesday, 19 June 2018 at 15:03:49 UTC, wjoe wrote: But maybe I missed something else and the only purpose of D is to make console applications for *NIX like OSs and expect users to be professional enough to save that stack trace before they close the terminal ? I just read stack trace from console. Initially D ecosystem focused on windows console applications, linux support came later, and compiling windows gui application is not straightforward. Simply because console support is the first thing to implement. And how can you be sure that this bug didn't corrupt memory of the druntime or anything else related to the stack trace, or even that it is a single bug ? The state is invalid in a sense that program shouldn't continue to serve its intended purpose. Either it is invalid, or if it is safe for the druntime to assume that it's safe to do whatever it does, then it's just as safe to assume that an installed signal handler called by the OS is doing it's thing just fine as well, like stopping a motor. And how useful is a stack trace that shows a back trace to the point of the location the Error was thrown compared to a back trace to the location of the bug (report)? In most cases stack trace is enough to diagnose the error. In most cases errors are easy to fix, too. I worry about the corner cases. The really annoying bugs. The bugs you might only get one shot at because you don't know how to reproduce, which you can only diagnose and fix via post mortem debugging. and provides a better UX than a core dump (especially to Please explain. A core dump has everything a printed stack trace has and more and is as easy as using the debugger itself. Do you know how to extract information from it on an unfamiliar OS? Reading stack trace is easier and self-evident. Counter question: How do you develop for an unfamiliar OS with unfamiliar tools in the first place ? The concept of a debugger and a memory dump is fundamentally the same on every OS I know or care about just as much as the D error implementation doesn't care about niche cases. Of course you can debug your applications via print to console if you feel that this is productive enough and ignore the bugs you can't fix that way.
Re: Nothrow std.conv.to with explicit default value
On Wednesday, 20 June 2018 at 14:39:48 UTC, Per Nordlöw wrote:
Is there a way to avoid compile-time-string-concat plus mixin
here?
Using __traits(getMember, ...) should compile faster, right?
T toDefaulted(T)(scope const(char)[] value, T defaultValue) @safe
pure nothrow @nogc
if (is(T == enum))
{
// doesn't need `std.conv.to`
switch (value)
{
static foreach (member; __traits(allMembers, T)) //
prevents call to slower `EnumMembers`
{
case member:
return __traits(getMember, T, member); // NOTE this
is slower: mixin(`return T.` ~ member ~ `;`);
}
default:
return defaultValue;
}
}
Re: Quick Refresher book?
On Saturday, 16 June 2018 at 23:33:18 UTC, Aedt wrote: Hello, I was wondering if there's any quick refresher resource to brush up on my D after a long time? Is there a short and quick language reference book like "A Tour of C++"? If you want to practice your coding skills I recommend you to start practicing on InterviewBit.com - https://www.interviewbit.com/courses/programming/ they organize the questions by topic and gamified it. This helped me to stay motivated.
