Re: dirEntries within static foreach: memory.d(827): Error: fakePureErrno cannot be interpreted at compile time, because it has no available source code
On Monday, 11 February 2019 at 01:05:05 UTC, kdevel wrote: On Monday, 11 February 2019 at 00:54:27 UTC, Seb wrote: On Monday, 11 February 2019 at 00:19:02 UTC, kdevel wrote: [...] You can't read or list files at compile-time. dmd can read files at compile time using the import function [1] Sorry, I should have rephrased: you can't call any OS-level functions at compile-time. This includes std.file.read and std.file.dirEntries.
Re: dirEntries within static foreach: memory.d(827): Error: fakePureErrno cannot be interpreted at compile time, because it has no available source code
On Monday, 11 February 2019 at 00:54:27 UTC, Seb wrote:
On Monday, 11 February 2019 at 00:19:02 UTC, kdevel wrote:
[...]
You can't read or list files at compile-time.
dmd can read files at compile time using the import function [1]
What are you trying to do?
Incorporate HTML template files into a CGI binary. After putting
[ and ] around the list in LS this works:
```TemplateStore.d
module TemplateStore;
import std.path;
import std.conv;
import std.file;
immutable string[string] template_map;
static this ()
{
immutable LS = import (`LS`);
immutable template_files = mixin(LS);
static foreach (f; template_files) {
pragma (msg, `reading template <` ~ f ~ ">");
template_map[f] = import (f);
}
}
```
[1]
https://forum.dlang.org/thread/njnwacxnvxlwlpjcu...@forum.dlang.org
Re: dirEntries within static foreach: memory.d(827): Error: fakePureErrno cannot be interpreted at compile time, because it has no available source code
On Sunday, February 10, 2019 5:19:02 PM MST kdevel via Digitalmars-d-learn
wrote:
> I am trying to get this code compiled:
>
> ```TemplateStore.d
> module TemplateStore;
> import std.path;
> import std.conv;
> import std.file;
>
> immutable string[string] template_map;
>
> static this ()
> {
> static foreach (f; dirEntries (``, `*.html`,
> SpanMode.shallow)) {
>pragma (msg, `reading template <` ~ f ~ ">");
>template_map[f] = import (f);
> }
> }
> ```
>
> dmd v2.082.0 says
>
> ...linux/bin64/../../src/druntime/import/core/memory.d(827):
> Error: fakePureErrno cannot be interpreted at compile time,
> because it has no available source code
> Error: invalid foreach aggregate
> Error: invalid foreach aggregate
>
> If I use an immutable array of file names instead of dirEntries
> the code compiles, but I don't want to update that array each
> time a new template file is added.
>
> As a workaround I wrote a helper which writes the quoted
> filenames comma-separated into a file named `LS` using this
> fragment:
>
> foreach (f; dirEntries (``, `*.html`, SpanMode.shallow))
>writefln ("`%s`,", f);
>
> Then I try to convince the dmd compiler to read LS and use its
> content as initializer for the immutable array template_files:
>
> immutable LS = import (`LS`);
> pragma (msg, `LS = <` ~ LS ~ `>`);
> immutable template_files = [
>mixin(LS)
> ];
>
> dmd now says (1) if the list in LS has a trailing comma:
>
> TemplateStore.d-mixin-13(26): Error: expression expected, not
> End of File
>
> or (2) if the list has no trailing comma:
>
> TemplateStore.d-mixin-13(13): Error: Using the result of a
> comma expression is not allowed
> TemplateStore.d-mixin-13(14): Error: Using the result of a
> comma expression is not allowed
> TemplateStore.d-mixin-13(15): Error: Using the result of a
> comma expression is not allowed
>
>
> What can I do about it?
Nothing. You can't call C functions during CTFE, because the compiler
doesn't have their source code, and all functions that interact with the
filesystem have to ultimately call C functions. So, you can't use something
like dirEntries with CTFE.
The only way that you can do anything along the lines of reading files
during CTFE is to use string imports to insert the text of a file directly
into the module.
- Jonathan M Davis
Re: dirEntries within static foreach: memory.d(827): Error: fakePureErrno cannot be interpreted at compile time, because it has no available source code
On Monday, 11 February 2019 at 00:19:02 UTC, kdevel wrote: I am trying to get this code compiled: ```TemplateStore.d module TemplateStore; import std.path; import std.conv; import std.file; [...] You can't read or list files at compile-time. What are you trying to do?
dirEntries within static foreach: memory.d(827): Error: fakePureErrno cannot be interpreted at compile time, because it has no available source code
I am trying to get this code compiled:
```TemplateStore.d
module TemplateStore;
import std.path;
import std.conv;
import std.file;
immutable string[string] template_map;
static this ()
{
static foreach (f; dirEntries (``, `*.html`,
SpanMode.shallow)) {
pragma (msg, `reading template <` ~ f ~ ">");
template_map[f] = import (f);
}
}
```
dmd v2.082.0 says
...linux/bin64/../../src/druntime/import/core/memory.d(827):
Error: fakePureErrno cannot be interpreted at compile time,
because it has no available source code
Error: invalid foreach aggregate
Error: invalid foreach aggregate
If I use an immutable array of file names instead of dirEntries
the code compiles, but I don't want to update that array each
time a new template file is added.
As a workaround I wrote a helper which writes the quoted
filenames comma-separated into a file named `LS` using this
fragment:
foreach (f; dirEntries (``, `*.html`, SpanMode.shallow))
writefln ("`%s`,", f);
Then I try to convince the dmd compiler to read LS and use its
content as initializer for the immutable array template_files:
immutable LS = import (`LS`);
pragma (msg, `LS = <` ~ LS ~ `>`);
immutable template_files = [
mixin(LS)
];
dmd now says (1) if the list in LS has a trailing comma:
TemplateStore.d-mixin-13(26): Error: expression expected, not
End of File
or (2) if the list has no trailing comma:
TemplateStore.d-mixin-13(13): Error: Using the result of a
comma expression is not allowed
TemplateStore.d-mixin-13(14): Error: Using the result of a
comma expression is not allowed
TemplateStore.d-mixin-13(15): Error: Using the result of a
comma expression is not allowed
:
What can I do about it?
Re: Handling big FP numbers
On Sunday, 10 February 2019 at 21:27:43 UTC, Dennis wrote:
On Sunday, 10 February 2019 at 20:25:02 UTC, Murilo wrote:
It seems this is a feature of D I will have to get used to and
accept the fact I can't always get the same number as in C
What compilers and settings do you use? What you're actually
comparing here are different implementations of the C runtime
library.
```
#include
int main() {
double a = 991234307654329925.7865;
printf("%f\n", a);
return 0;
}
```
I compiled this with different C compilers on Windows 10 and
found:
DMC: 99123429947200.00
GCC: 9912342990.00
CLANG: 991234299470108672.00
As for D:
```
import core.stdc.stdio: printf;
int main() {
double a = 991234307654329925.7865;
printf("%f\n", a);
return 0;
}
```
DMD: 99123429947200.00
LDC: 991234299470108672.00
DMC and DMD both use the Digital Mars runtime by default. I
think CLANG and LDC use the static libcmt by default while GCC
uses the dynamic msvcrt.dll (not sure about the exact one, but
evidently it's different). So it really hasn't anything to do
with D vs. C but rather what C runtime you use.
Ahhh, alright, I was not aware of the fact that there are
different runtimes, thanks for clearing this up.
Re: Easiest way to display images
On Sunday, 10 February 2019 at 21:26:56 UTC, Adam D. Ruppe wrote: On Sunday, 10 February 2019 at 18:42:59 UTC, Murilo wrote: Adam, is there a place where we can chat? I don't like chatting via this forum. I would like to talk to you about your modules and about the D lang. get on the freenode irc, i am in #d like all the time (and will see messages when i am back on my computer) or you can dm me adam_d_ruppe there if i am online okay, I will try that, but do you have a facebook account? I usually chat with people on facebook.
Re: Handling big FP numbers
On Sunday, 10 February 2019 at 20:25:02 UTC, Murilo wrote:
It seems this is a feature of D I will have to get used to and
accept the fact I can't always get the same number as in C
What compilers and settings do you use? What you're actually
comparing here are different implementations of the C runtime
library.
```
#include
int main() {
double a = 991234307654329925.7865;
printf("%f\n", a);
return 0;
}
```
I compiled this with different C compilers on Windows 10 and
found:
DMC: 99123429947200.00
GCC: 9912342990.00
CLANG: 991234299470108672.00
As for D:
```
import core.stdc.stdio: printf;
int main() {
double a = 991234307654329925.7865;
printf("%f\n", a);
return 0;
}
```
DMD: 99123429947200.00
LDC: 991234299470108672.00
DMC and DMD both use the Digital Mars runtime by default. I think
CLANG and LDC use the static libcmt by default while GCC uses the
dynamic msvcrt.dll (not sure about the exact one, but evidently
it's different). So it really hasn't anything to do with D vs. C
but rather what C runtime you use.
Re: Easiest way to display images
On Sunday, 10 February 2019 at 18:42:59 UTC, Murilo wrote: Adam, is there a place where we can chat? I don't like chatting via this forum. I would like to talk to you about your modules and about the D lang. get on the freenode irc, i am in #d like all the time (and will see messages when i am back on my computer) or you can dm me adam_d_ruppe there if i am online
Re: Handling big FP numbers
On Saturday, 9 February 2019 at 05:46:22 UTC, H. S. Teoh wrote: On Sat, Feb 09, 2019 at 03:52:38AM +, Murilo via Digitalmars-d-learn wrote: On Saturday, 9 February 2019 at 03:28:24 UTC, Adam D. Ruppe wrote: [...] > But you can change this with the format specifiers (use > `writefln` instead of `writeln` and give a precision > argument) or, of course, you can use the same C printf > function from D. Thanks, but which precision specifier should I use? I already tried "%.20f" but it still produces a result different from C? Is there a way to make it identical to C? I say again, you're asking for far more digits than are actually there. The extra digits are only an illusion of accuracy; they are essentially garbage values that have no real meaning. It really does not make any sense to print more digits than are actually there. On the other hand, if your purpose is to export the double in a textual representation that guarantees reproduction of exactly the same bits when imported later, you could use the %a format which writes out the mantissa in exact hexadecimal form. It can then be parsed again later to reproduce the same bits as was in the original double. Or if your goal is simply to replicate C behaviour, there's also the option of calling the C fprintf directly. Just import core.stdc.stdio or declare the prototype yourself in an extern(C) declaration. T Thanks, but even using core.stdc.stdio.fprintf() it still shows a different result on the screen. It seems this is a feature of D I will have to get used to and accept the fact I can't always get the same number as in C even though in the end it doesn't make a difference cause as you explained the final digits are just garbage anyway.
Re: Query for -dip1000
On Sunday, 10 February 2019 at 20:04:29 UTC, Per Nordlöw wrote: Or do I have to write a trait myself? Oops, I had already posted that and got an answer at https://forum.dlang.org/post/qglynupcootocnnnp...@forum.dlang.org
Query for -dip1000
Is there a way to query if the -dip1000 flag has been passed to
the compiler? I need it for enabling certain DIP-1000 escape
analysis tests only when -dip1000 has been passed.
For instance
static assert(!__traits(compiles, {
char[] f()
{
char[2] x;
return x[].splitterASCII!(_ => _ == '
').front;
}
}));
at
https://github.com/nordlow/phobos-next/blob/bd2fe42978aab2313977042c858d77c5766538e8/src/splitter_ex.d#L110
Or do I have to write a trait myself?
Re: Easiest way to display images
On Wednesday, 6 February 2019 at 03:35:03 UTC, Adam D. Ruppe wrote: On Wednesday, 6 February 2019 at 01:04:43 UTC, Murilo wrote: You should later joing the facebook group Programming in D. Eh, I don't really like facebook groups. With my libraries too, I don't really care if anyone uses them. I make them for myself and put them online because it is easy for me. I don't count downloads or anything; it just means nothing to me. Adam, is there a place where we can chat? I don't like chatting via this forum. I would like to talk to you about your modules and about the D lang.
Re: Should D file end with newline?
On Sunday, February 10, 2019 2:06:50 AM MST Cym13 via Digitalmars-d-learn wrote: > On Sunday, 10 February 2019 at 02:12:43 UTC, Jonathan M Davis > > wrote: > > On Saturday, February 9, 2019 2:19:27 PM MST Victor Porton via > > > > Digitalmars- d-learn wrote: > >> ISO C++ specifies that the C++ file must end with a newline. > >> > >> Should D file end with newline, too? > > > > No, there is no need to end D files with a newline. I would > > guess that the vast majority of D files end with a closing > > brace. I just looked at a bunch of files in the standard > > library for the heck of it, and almost all of the ones I looked > > at ended with a closing brace. And those that didn't ended with > > something like an enum declaration and not a newline. > > Personally, I don't leave newlines at the end of files, because > > it looks messy. I don't even recall doing that in C++, though I > > do recall that there supposedly be a rule about it. It seems > > like a pretty bizarre requirement to me, but regardless, I'm > > quite sure that D does not have that requirement. > > > > - Jonathan M Davis > > If you used a text editor or IDE to write that final closing > brace then I'm pretty confident it does add the newline character > at the end. That won't result in an empty line on display. Try > using an hex editor to check if you're curious. I use (g)vim, which I would expect to show anything like trailing newlines. It usually shows everything, including rendering control characters and the like in a way that you know exactly what's there. Opening up std/algorithm/mutation.d in vim as an example, it clearly ends in a closing brace with no trailing newline. However if I feed it into hexdump ... 00158f0 2020 6373 706f 2865 7865 7469 2029 7266 0015900 6565 7328 702e 7274 3b29 7d0a 000a 001590d hexdump shows a newline followed by a null character followed by a newline after the carriage return. So, it does indeed look like extra junk is there after the data in the file, and surprisingly, vim doesn't showing it (or anything indicating that it's there). I don't know why any of that would be there, since it seems pointless me, but it is there in std/algorithm/mutation.d. On the other hand, if I open up std/datetime/systime.d with hexdump, it shows 007f8b0 0a7d 2020 2020 2020 2020 0a7d 2020 2020 007f8c0 0a7d 0a7d 007f8c4 so it actually ends on a closing braces. So, maybe some text editors shove extra junk on the end and others don't? I don't know. Either way, I find it very odd that vim doesn't show anything after the closing brace when it's there. Both of those files show a closing brace as their last character when opened in vim. Looking quickly at some of my personal projects, I don't see any files which end with anything other than a closing brace according to either vim or hexdump. And since all of those were created with (g)vim, I'd say that vim does not put those extra characters on the end (though it will allow them and otherwise ignore them). That also makes it clear that no newline or any other special sequence of characters is required at the end of a .d file, because all of those files work just fine with their last character being a closing brace. Curiously, if I create a .cpp or .c file with vim and have it end with a curly brace, vim _does_ append a newline followed by a null character followed by a newline at the end of the file. So, I guess that vim looks at the extension and realizes that C/C++ has such a requirement and takes care of it for you, but it does not think that .d files need them and adds nothing extra for them. It doesn't add anything for a .txt file when I tried it either. In any case, if your text editor happens to insert those extra characters at the end of a .d file, then they may end up there, but given what hexdump says and what dmd accepts, I can verify that they aren't actually required for .d files. - Jonathan M Davis
Re: A predicate with different argument types
auto sorted = object_.assumeSorted!((a, b) => a.name < b.name); Sorry for the copy-paste. It should be "attributes" in place of "object_" here, of course: auto sorted = attributes.assumeSorted!((a, b) => a.name < b.name);
A predicate with different argument types
Is it possible to make a comparison predicate with different
argument types? For instance, suppose I have a struct like this:
struct Attribute {
string name;
variant value;
}
Also, suppose I have a sorted vector of such values. So I can
quickly find one by its name field and I have index-based random
access to elements at the same time. Therefore I have something
like this:
Attribute[] attributes;
Now, imagine I try to find an insertion position for a new
element:
string name; // input data
auto sorted = object_.assumeSorted!((a, b) => a.name < b.name);
Attribute dummy;
dummy.name = name;
auto pos = sorted.lowerBound(dummy);
It works fine but is there a way to get rid of the 'dummy'
object? I can easily achieve that in C++ since STL allows to have
a predicate with different argument types. Ideally, I'd like
something like this:
string name; // input data
auto sorted = object_.assumeSorted!((a, b) => a.name < name);
auto pos = sorted.lowerBound(name);
Thanks.
Re: Trying to extract string from curl redirected URL
On Sunday, 10 February 2019 at 14:12:02 UTC, Josh wrote:
Is there something I'm missing? It it possible to access the
private handle? Is there a better way to do what I'm trying to
achieve?
Assuming I'm understanding your question (you want to get the
path of a URL after redirects), if you're not adverse to
dependencies you could use requests;
https://code.dlang.org/packages/requests.
Create a Request, query an URL for a Response and then access its
finalURI member. Then parse the path string normally to get the
session ID, such as with std.algorithm.findSplit and friends or
with regex.
import requests;
Request req;
Response res = req.get("https://website.com/;);
string id = res.finalURI.path
.findSplit("?s=")[2]
.findSplitBefore("&")[0];
if (!id.length) { /* no ID in URL */ }
Trying to extract string from curl redirected URL
I have a website (say https://website.com) that I need to log in to, it will do a few 302 redirects and then I will end up with a unique session ID in the URL (such as https://website.com/welcome.html?s=636853677441448706). Is there some way of extracting this ID (I'll need it later for other things)? I'm using std.net.curl's HTTP, and when I turn verbose on and do the login POST I can see that it is in fact redirecting to the URL with the session ID. I can see that etc.c.curl has CurlInfo.effective_url and CurlInfo.redirect_url that I can use with curl_easy_getinfo, but that needs a CURL*. HTTP.handle.handle is private, so I can't get a CURL* out of the Curl struct. Is there something I'm missing? It it possible to access the private handle? Is there a better way to do what I'm trying to achieve?
Re: Should D file end with newline?
On Sunday, 10 February 2019 at 02:12:43 UTC, Jonathan M Davis wrote: On Saturday, February 9, 2019 2:19:27 PM MST Victor Porton via Digitalmars- d-learn wrote: ISO C++ specifies that the C++ file must end with a newline. Should D file end with newline, too? No, there is no need to end D files with a newline. I would guess that the vast majority of D files end with a closing brace. I just looked at a bunch of files in the standard library for the heck of it, and almost all of the ones I looked at ended with a closing brace. And those that didn't ended with something like an enum declaration and not a newline. Personally, I don't leave newlines at the end of files, because it looks messy. I don't even recall doing that in C++, though I do recall that there supposedly be a rule about it. It seems like a pretty bizarre requirement to me, but regardless, I'm quite sure that D does not have that requirement. - Jonathan M Davis Doing a quick a quick tail on all the source files for dmd, druntime and phobos, I only found 6 source files that ended in a curly brace and 2 ending in a 'g'. All others ended with a newline. Its certainly not required but it is common in the style guides I've seen and I personally have my editor automatically insert a newline.
Re: Should D file end with newline?
On Sunday, 10 February 2019 at 02:12:43 UTC, Jonathan M Davis wrote: On Saturday, February 9, 2019 2:19:27 PM MST Victor Porton via Digitalmars- d-learn wrote: ISO C++ specifies that the C++ file must end with a newline. Should D file end with newline, too? No, there is no need to end D files with a newline. I would guess that the vast majority of D files end with a closing brace. I just looked at a bunch of files in the standard library for the heck of it, and almost all of the ones I looked at ended with a closing brace. And those that didn't ended with something like an enum declaration and not a newline. Personally, I don't leave newlines at the end of files, because it looks messy. I don't even recall doing that in C++, though I do recall that there supposedly be a rule about it. It seems like a pretty bizarre requirement to me, but regardless, I'm quite sure that D does not have that requirement. - Jonathan M Davis If you used a text editor or IDE to write that final closing brace then I'm pretty confident it does add the newline character at the end. That won't result in an empty line on display. Try using an hex editor to check if you're curious.
