Re: How to add an additional config dir in DUB under source?
On Tuesday, 13 October 2020 at 05:13:18 UTC, Mike Parker wrote: not available. The very first restriction on CTFE is this: "The function source code must be available to the compiler. Functions which exist in the source code only as extern declarations cannot be executed in CTFE." Forgot the link: https://dlang.org/spec/function.html#interpretation
Re: How to add an additional config dir in DUB under source?
On Monday, 12 October 2020 at 22:31:53 UTC, tastyminerals wrote:
I wonder why and what am I doing wrong?
This:
readText("conf.toml");
"stringImportPath" (dmd's -J command line option) is specifically
for D's import expression (which is different from the import
statement, e.g., `import std`):
https://dlang.org/spec/expression.html#import_expressions
It has no effect on arbitrary filesystem calls. And, in fact,
filesystem calls cannot be called at compile-time because they
ultimately depend on system calls for which the source code is
not available. The very first restriction on CTFE is this:
"The function source code must be available to the compiler.
Functions which exist in the source code only as extern
declarations cannot be executed in CTFE."
So if you were to do something like, `enum foo =
readText("foo.txt")`, you would get a compile time error. On
Windows:
"Error: CreateFileW cannot be interpreted at compile time,
because it has no available source code"
You're calling `readText` in a normal runtime context, so it's
looking file at runtime relative to the current working directory.
What you need to do is something like this:
```
string config = import("config.toml");
void loadConfig() {
// parse config string here
}
```
I don't know where the `EmbeddedPNG` template comes from, but it
has to be using the import expression internally, else it
wouldn't work.
Re: Renaming Flag!"" in API
On Monday, 12 October 2020 at 16:44:52 UTC, Ali Çehreli wrote: It's amazing how things come together before each conference. Flag appears among my slides for an upcoming conference as well! :) But I don't think there is any solution to your problem. On 10/12/20 3:24 AM, FreeSlave wrote: > Later I realize that 'myflagname' is a bad name and I want to change it > to something else. But if I do so, I break the existing code using this > API as Flag with different name will be a different type This is essentially the same as one of the objections to named arguments. Ali Huh, never thought about named arguments in this way. Yet some syntax for parameter name aliasing could be invented to refer to the same parameter by different names if D ever gets named arguments feature.
How to add an additional config dir in DUB under source?
I have the following project structure:
source/
media/
icon.png
config/
conf.toml
In order to access "icon.png" without explicitly providing the
path I added in dub.json
"stringImportPaths": [
"source/media",
"source/config"
]
It works for "icon.png" but doesn't work for "conf.toml". The
"icon.png" can be accessed and the code below works:
addEntry(new EmbeddedPng!("quit.png")
but std.file: readText refuses to see "conf.toml":
readText("conf.toml");
file.d(371): conf.toml: No such file or directory
I wonder why and what am I doing wrong?
Re: vibe.d / experience / feedback
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote: Go seems to be kept as simple as possible, even if you have to write more code. Which is, in the long run, the cheaper and smaller burden. No tricks, no surprises... that has a lot of merits. Btw, Go has some major weaknesses related to tricks and surprises: 1. No exceptions... they encourage old 70s-style checking of errors everywhere. That makes code much less readable. It is possible to roll your own mechanism using their panic() feature, but most Go enthusiasts frown upon that. (ignore them, they are clueless) 2. Not as strong typing as it should have. Things related to interfaces may not be detected until runtime if you get sloppy with it. (avoid very generic interfaces) 3. I believe dynamic arrays are reallocated automatically, like in D. So in Go, if you extend a dynamic array it will relocate and old slices will peek to the old copy: a := make([]int, 3) b := a[:] a = append(a,4,5,6) b[2] = 3; fmt.Println(a) fmt.Println(b) output: [0 0 0 4 5 6] [0 0 3] So you have to define your own coding standard to avoid such issues. Basically, ignore what is touted as Go idioms and create a ruleset that makes sense for you.
Phobos Unittesting
I'm working on adding support for Windows' symlinks in std.file.
std.file.symlink's augmentation is straightforward, but testing
it is not as easy. The reason is because, normally, one must
confer escalated privileges to the executable making the link via
CreateSymbolicLink[A|W]. This may be obviated, in Windows 10 at
least, by enabling "Developer mode" and passing a flag to the
aforementioned function.
Thus, consider what I have right now:
auto flags = /* Default flags */;
version (StdUnittest)
{
flags |= SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE;
}
By doing this, running tests shouldn't require administrator's
rights, assuming "Developer mode" is enabled. However, are the
Windows CI machines set up for this? Should there be a special
case at all?
The final concern relates to Phobos defining system_directory and
system_file for Posix and Android. These two constants are used
in testing some of std.file's functionality. For Windows, a
testing directory could be %temp% and the testing file could be
created in that directory. If my changes were approved, the file
would only have to be created twice throughout std.file's tests.
However, I'd like to know some alternatives and potential issues
to/with this!
Re: vibe.d / experience / feedback
On Monday, 12 October 2020 at 11:21:40 UTC, Robert M. Münch wrote: Even most people seem to use Go for the web services stuff, I think it might be underrate for desktop apps. Go is good at what it has Go libraries for, and I believe it has gotten quite a few over the past years, some that has been translated from Python. If you look at some of the awesome-go-lists on github then you get a picture of whether it will be a good fit for your project.
Re: List of exceptions?
On 10/12/20 2:11 AM, Dominikus Dittes Scherkl wrote: > - Throw exceptions only if you have a plan what to do with them if you > catch them. My thinking is different: Throw exceptions if you can't accomplish a task. My code is filled with enforce() and assert() checks, which do throw exceptions. > - If you have no plan, better throw error, just to get an idea where and > why the program crashed (and don't try to catch them) In most cases, catching Exception (not Error) to print exc.msg is fine and is the correct thing to do. (Errors are not caught, the stack trace is printed, and that's helpful.) Occasionally, exc.msg of an Exception doesn't give enough information. So, printing exc (not exc.msg) temporarily to look at the stack trace is helpful. Ali
Re: Renaming Flag!"" in API
It's amazing how things come together before each conference. Flag appears among my slides for an upcoming conference as well! :) But I don't think there is any solution to your problem. On 10/12/20 3:24 AM, FreeSlave wrote: > Later I realize that 'myflagname' is a bad name and I want to change it > to something else. But if I do so, I break the existing code using this > API as Flag with different name will be a different type This is essentially the same as one of the objections to named arguments. Ali
Re: Renaming Flag!"" in API
On Monday, 12 October 2020 at 11:34:25 UTC, Vladimir Panteleev wrote: On Monday, 12 October 2020 at 10:24:44 UTC, FreeSlave wrote: Can this issue overcome somehow? Why not add a deprecated overload for your function which takes the old Flag value? I thought about overloading too. Templatizing the parameter is fitting too especially if the function is already templated. I think I'll go with the latter. Yet in general it would be a tedious work to add template constraints or overloads (and in case of overloads there's also a lot of copy-pasting included) to all functions that use this flag as parameter if there were too many of them. Some way to declare two flag types as implicitly convertable would be nice.
Re: Can I measure how much memory is used in total, grouped by type?
On Sunday, 11 October 2020 at 20:58:22 UTC, drathier wrote: I think I'm using way to much memory for pointers, so I'd like to see how much of my memory usage is taken up by pointers. I've calculated the answer, but I wonder if the compiler/runtime could do it for me, to get a faster and more exact number? More specifically, can I do this for a single value? E.g. how much memory is used by pointer types in this specific variable?
Re: Renaming Flag!"" in API
On 10/12/20 7:34 AM, Vladimir Panteleev wrote: On Monday, 12 October 2020 at 10:24:44 UTC, FreeSlave wrote: Can this issue overcome somehow? Why not add a deprecated overload for your function which takes the old Flag value? Or even not deprecated (if it still makes sense). -Steve
Re: Win32Api GetDlgItemText How make buffer with no fixed size?
On Saturday, 10 October 2020 at 12:31:14 UTC, Adam D. Ruppe wrote: On Saturday, 10 October 2020 at 10:15:03 UTC, Marcone wrote: wchar[100] buffer; // I don't want fixed size :( wchar[] buffer; // no fixed size buffer.length = GetWindowTextLength(hwn); // set it to the text length of the window // now get the text GetDlgItemText(hwn, widget, buffer.ptr, buffer.length); Use buffer.length instead of buffer.sizeof in D. Very good! working fine. Thank you.
Re: Wanted! Tree Node implementation.
On Wednesday, 7 October 2020 at 14:31:20 UTC, Виталий Фадеев
wrote:
Wanted! Tree Node implementation.
Like a:
mixin template TreeNode( T )
{
T parent;
T firstChild;
T lastChild;
T prevSibling;
T nextSibling;
// ForwardRange implementation
@property T front() { ... }
@property bool empty() { ... }
void popFront() { ... }
// BackwardRange implementation
@property T back() { ... }
void popBack();
// RandomAccessRange implementation
T opIndex( ... ) { ... }
// length implementation
@property size_t length() { ... }
}
It would be nice to get a link or package or source...
You can peak into the stdlibrary, how they do it:
https://github.com/dlang/phobos/blob/master/std/container/rbtree.d
Re: Renaming Flag!"" in API
On Monday, 12 October 2020 at 10:24:44 UTC, FreeSlave wrote: Can this issue overcome somehow? Why not add a deprecated overload for your function which takes the old Flag value?
Re: vibe.d / experience / feedback
On Monday, 12 October 2020 at 11:21:40 UTC, Robert M. Münch wrote: On 12 Oct 2020 at 13:13:27 CEST, "Ola Fosheim Grøstad" wrote: Yes, it is a good fit for web services with medium sized code bases. We don't have a lot of "big project" experience with Go yet, but we would use it for a plain-old desktop application. Even most people seem to use Go for the web services stuff, I think it might be underrate for desktop apps. Viele Grüsse. Just to avoid a wrong impression, there are also a lot of projects using vibe-d with great success (small companies and big size enterprises). In my case I needed a websocket server, which will run on Kubernetes. The documentation was available and usable. Also a sample was available as far as I remember. I had here the "get things done" experience. Kind regards Andre
Re: Renaming Flag!"" in API
On Monday, 12 October 2020 at 10:24:44 UTC, FreeSlave wrote:
Let's say I use Flag type named 'myflagname' in API like this:
import std.typecons;
void func(Flag!"myflagname" flag)
{
//...
}
void main()
{
func(Yes.myflagname);
}
Later I realize that 'myflagname' is a bad name and I want to
change it to something else. But if I do so, I break the
existing code using this API as Flag with different name will
be a different type and Yes.myflagname and No.myflagname won't
fit in. I can't use alias as Yes and No relies on string
literal.
Can this issue overcome somehow? Looks like a fundamental flaw
with std.typecons.Flag.
One of the reason's Flag is there is because of what's known as
the boolean trap [0]. If someone changes the name of a parameter,
that can potentially mean the semantics have changed. Should Flag
work then? And if it should, why not straight up bool?
https://wiki.qt.io/API_Design_Principles#The_Boolean_Parameter_Trap
Re: vibe.d / experience / feedback
On 12 Oct 2020 at 13:13:27 CEST, "Ola Fosheim Grøstad" wrote: > Yes, it is a good fit for web services with medium sized code > bases. We don't have a lot of "big project" experience with Go yet, but we would use it for a plain-old desktop application. Even most people seem to use Go for the web services stuff, I think it might be underrate for desktop apps. Viele Grüsse. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Range format specifiers in other languages?
On Mon, Oct 12, 2020 at 05:51:21AM +, Imperatorn via Digitalmars-d-learn
wrote:
> On Monday, 12 October 2020 at 00:59:33 UTC, Adam D. Ruppe wrote:
> > On Monday, 12 October 2020 at 00:46:37 UTC, Imperatorn wrote:
> > > To people trying to learn, why is that % before ( needed in the
> > > format string?
> >
> > The %( ... %) stuff is expanded and repeated for each element inside
> > the given array.
>
> Thanks, it seems there are some pretty powerful formatting options:
>
> https://dlang.org/phobos/std_format.html
Indeed.
%(...%) is one of my favorite because it can be nested, so it's a very
useful quick-n-dirty tool for debugging ranges. With .chunks and .map,
you can format just about any range-based data in a one-liner for
dumping debug info.
Another cool one is the `,` digit-grouper:
import std;
void main() {
writefln("%,2d", 1234567890);
writefln("%,3d", 1234567890);
writefln("%,4d", 1234567890);
writefln("%,3?d", '_', 1234567890);
writefln("%,4?d", '\'', 1234567890);
writefln("%,4?.2f", '\'', 1234567890.123);
}
Output:
12,34,56,78,90
1,234,567,890
12,3456,7890
1_234_567_890
12'3456'7890
12'3456'7890.12
T
--
Век живи - век учись. А дураком помрёшь.
Re: vibe.d / experience / feedback
On 11 Oct 2020 at 21:10:20 CEST, "tastyminerals" wrote: > And I feel like you guys will just pick Go because it will get > stuff done. That's the main focus from a company perspective. We try to waste as less time & money as possible. > When I just started learning about D ecosystem, vibe frequently > popped up as one of the popular frameworks available for the > language AND also a reason for ppl to jump in and try out D. I love D, like it a lot, follow it for many years, use it from time to time... but it's not about me, but a team and a product we need to develop and maintain. There are much more non-technical aspects important then technical... And, deciding about your tech-stack base is a path-dependent decision. Turning to something else, has a very high cost impact. > However, as time goes, I also pick up many complaints about vibe, > its performance and ease of use compared to competitors. This > post just solidifies the impression. Bad documentation is the > worst thing that can happen to a project which gets promoted as a > one of the gems of the language ecosystem and actually hurts the > language image much more than does good. Sigh... Well... I expect a lot of people taking a look at D do it like we do with other solutions: I take a list of things I want to try out and start the timer to see how long I take to get it done. This gives a good impression of the eco-system, etc. Taking a step back, D looks a bit scattered. A lot of stuff is there, the standard lib is pretty good, many half-done packages, many corners to take a look at. D is a big language, with a lot of concepts to learn and building up experience is not fast. > I will never advice vibe to anyone because I know that better alternatives > exist. People will use Go, Python, Ruby, Rust whatever has better > docs to get it running fast and not risk wasting time. I'm pretty sure Vide is suitable for all kind of applications today. But you need to have a higher "experimentation" scope in what you do. Once you build up experience with all this stuff, I think there is no big difference to other approaches. But the question is how long is this? 1, 2, X years? > Sadly, this is how some languages grow and some don't. And it's > not all about the corporate support, hype, GC or random luck, > it's about cases like the above. I think less is more, and D is pretty huge tpday. And, it's an OS project, so people do what makes fun. Go is mostly driving from a corporate perspective and the OS part is a side aspect. That has some merits too. Viele Grüsse. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: vibe.d / experience / feedback
On Monday, 12 October 2020 at 11:06:55 UTC, Robert M. Münch wrote: Go seems to be kept as simple as possible, even if you have to write more code. Which is, in the long run, the cheaper and smaller burden. No tricks, no surprises... that has a lot of merits. Yes, it is a good fit for web services with medium sized code bases. Or for Google Cloud Functions. Then you write one program for each request handler. This is where I am heading. The advantage with such a solution is that you can write one handler in Python, another in Go and perhaps one in node.js.
Re: vibe.d / experience / feedback
On 11 Oct 2020 at 16:46:13 CEST, "Ola Fosheim Grøstad" wrote: > Ada, Java, Eiffel are supposed to. Yes... beside Java, the other two are already in the exotic department... > I'm not sure if Go is a success in that department either. I > suspect it tanks when programs get large. Go seems to be kept as simple as possible, even if you have to write more code. Which is, in the long run, the cheaper and smaller burden. No tricks, no surprises... that has a lot of merits. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: List of exceptions?
On Monday, 12 October 2020 at 09:11:35 UTC, Dominikus Dittes Scherkl wrote: - ...not care about exceptions someone else defined...except for printing out their message in main()... - ...not reuse exceptions defined by someone else. Define your own. - ...only if you have a plan... - ...no plan, better throw error...where and why the program crashed... Therefore a list of possible exceptions doesn't make any sense. Thanks, Dominikus, those are great ideas.
Re: Renaming Flag!"" in API
On Monday, 12 October 2020 at 10:24:44 UTC, FreeSlave wrote:
Let's say I use Flag type named 'myflagname' in API like this:
import std.typecons;
void func(Flag!"myflagname" flag)
{
//...
}
void main()
{
func(Yes.myflagname);
}
Later I realize that 'myflagname' is a bad name and I want to
change it to something else. But if I do so, I break the
existing code using this API as Flag with different name will
be a different type and Yes.myflagname and No.myflagname won't
fit in. I can't use alias as Yes and No relies on string
literal.
Can this issue overcome somehow? Looks like a fundamental flaw
with std.typecons.Flag.
Once encountered a similar situation. Flag was good but once you
know your API, and as in my case I was the only user, I just
replaced with a template param + constraint.
In the worst case, let's say you forget a bit the API, a DDOC
popup can help.
example:
---
import std.typecons;
/* Params: T = anything convertible to bool
t = indicates whether do this or do that */
void func(T)(T t) if (is(T : bool)){}
void main()
{
enum yn { yes = true, no = false}
// all good, all same semantic
func(yn.yes);
func(true);
func(Yes.myflagname);
}
---
Renaming Flag!"" in API
Let's say I use Flag type named 'myflagname' in API like this:
import std.typecons;
void func(Flag!"myflagname" flag)
{
//...
}
void main()
{
func(Yes.myflagname);
}
Later I realize that 'myflagname' is a bad name and I want to
change it to something else. But if I do so, I break the existing
code using this API as Flag with different name will be a
different type and Yes.myflagname and No.myflagname won't fit in.
I can't use alias as Yes and No relies on string literal.
Can this issue overcome somehow? Looks like a fundamental flaw
with std.typecons.Flag.
Re: List of exceptions?
On Saturday, 10 October 2020 at 19:51:10 UTC, DMon wrote: This is where I'm at: import std.stdio; import std.conv; // StdioException // ConvException // StringException // ErrnoException // FormatException // UnicodeException // UTFException // FileMissingException // DataCorruptionException // FE_INEXACT // FE_UNDERFLOW // FE_OVERFLOW // - You should not care about exceptions someone else defined in his library (maybe except for printing out their message in main(), for which you don't need to know the exact type). - You should not reuse exceptions defined by someone else. Define your own. - Throw exceptions only if you have a plan what to do with them if you catch them. - If you have no plan, better throw error, just to get an idea where and why the program crashed (and don't try to catch them) Therefore a list of possible exceptions doesn't make any sense.
Re: Count template parameters of method
And what about:
void test() {}
and
void text(alias qqq)() {}
?
