Re: exporting function from betterc to windows dll
On Saturday, 14 March 2020 at 20:53:45 UTC, Abby wrote:
I would like to export some functions from my bettec dll for
dotnet core application in windows.
Right now I have compiled dll using dmd v2.091.0-dirty simply
by ´dub build´
this is the function I have
extern(C) char* test_echo(const(char)* line, size_t len, ref
size_t resLen)
{
enum format = "{\"message\": \"%s\"}\n";
auto response = cast(char*)malloc(format.length + len);
resLen = sprintf(response, format, line);
return response;
}
and this is my dotnet core equivalent
[DllImport(DllName, CallingConvention =
CallingConvention.StdCall)]
static extern IntPtr
test_echo([MarshalAs(UnmanagedType.LPStr)]string line, ulong
len, out ulong resLen);
This works for me in linux but does not in windows, any idea
what I'm doing wrong?
For one thing, you're defining it with stdcall in dotnet, but
cdecl in the code. You should change the convention on the dotnet
side to CallingConvention.Cdecl. Or, if you really want to use
stdcall, use extern(System) in D -- the equivalent of
extern(Windows) on Windows and extern(C) everywhere else.
Also, I would expect you'd have to use export [1] on the D side
for the symbol to be loadable from the dll:
extern(C) export char* test_echo(...) { ... }
This should be the equivalent of __declspec(dllexport) for C and
C++ on Windows.
[1] https://dlang.org/spec/attribute.html#visibility_attributes
(Item #7)
Re: Is it possible to dynamically load a @safe function from a shared library ?
On Friday, 13 March 2020 at 16:11:53 UTC, wjoe wrote: On Friday, 13 March 2020 at 16:04:06 UTC, Mike Parker wrote: On Friday, 13 March 2020 at 15:16:06 UTC, wjoe wrote: bindSymbol(, "VersionOfAPI"); } Is it possible to convince the compiler to look the other way while binding @safe functions from the plugin ? It probably has nothing to do with @safe, but is because of the void**. bindSymbol(cast(void**), "VersionOfAPI"); Than works, thanks :) But isn't apiVersion a function pointer ? Yes, but when you take the address of *any* kind of pointer, you can't assign it to void** without a cast.
Re: Is it possible to dynamically load a @safe function from a shared library ?
On Friday, 13 March 2020 at 15:16:06 UTC, wjoe wrote: bindSymbol(, "VersionOfAPI"); } Is it possible to convince the compiler to look the other way while binding @safe functions from the plugin ? It probably has nothing to do with @safe, but is because of the void**. bindSymbol(cast(void**), "VersionOfAPI");
Re: total newbie + IDE
On Sunday, 9 February 2020 at 22:10:57 UTC, solnce wrote: Personally I feel this is more about lack of the vision, as Alexandrescu once said. Now it feels like D is mostly the compiler, but I think, that having one big mega project (like IDE+RAD) could give a new breath and significance to D language. There's absolutely no need for an IDE to be written in D (particularly one that supports RAD -- what would that use? GtkD?). For one thing, it's a massive project for which the D team does not have the resources to achieve. For another, there are already several popular IDEs and text editors for which plugins have been developed by community members. It would be a waste of time and energy for the D team to work on an IDE project. If someone is inspired to write an IDE in D (and some have been in the past), nothing is stopping them.
Re: readline / Gnu readline
On Thursday, 30 January 2020 at 06:27:36 UTC, Michael wrote: On Thursday, 30 January 2020 at 06:15:54 UTC, Mike Parker wrote: Is your source file named rl.d? And are you running dmd in the source file's directory? No, I did not. Changed it now and it works with dmd. Great! Tried the same with rdmd I'm getting a linker error. Take a look at the rdmd documentation: https://dlang.org/rdmd.html There you'll see this: rdmd [dmd and rdmd options] progfile[.d] [program arguments] That means any arguments you pass on the command line after the source file name will be passed to your program. Compiler options need to go before the source file name. rdmd -L-lreadline mysource.d
Re: readline / Gnu readline
On Thursday, 30 January 2020 at 06:12:32 UTC, Michael wrote: When 'dmd rl -L-lreadline' in the command line. I do get the following error: Error: module rl is in file 'rl.d' which cannot be read. So probably I'm missing something unfortunately I don't know what. Is your source file named rl.d? And are you running dmd in the source file's directory?
Re: How change window Backgound Color when press a Button when using "ResEdit Resource Editor" to design?
On Thursday, 30 January 2020 at 04:31:46 UTC, Marcone wrote: I am very noob. Can you send me the code? You've been asking a lot of questions about the Win32 API. This is a D programming forum, not a Win32 API forum. I'm sure people are generally happy to help point you in the right direction, but you can't rely on anyone to send you code for it. Not many people are doing Win32 API programming in D (and I would guess a large percentage of the community here have never touched it). You really need to be following a Win32 API tutorial to learn this stuff. I don't personally know how good any online Win32 tutorials are, but I do know that the book "Programming Windows 5th Edition" is an excellent resource for learning Win32 programming: https://amzn.to/37C6htu It's available in both hardcover and Kindle editions. If you can afford to get it, I highly recommend you do. Several years ago, Andrej Mitrovic translated many of the examples from that book to D. Even if you don't buy the book, this will be a good resource to help you: https://github.com/AndrejMitrovic/DWinProgramming
Re: weekly news?
On Thursday, 23 January 2020 at 15:44:10 UTC, Adam D. Ruppe wrote: Or delete all that wordpress junk and make something in D :P I intend to delete all that Wordpress junk and go completely static eventually.
Re: weekly news?
On Thursday, 23 January 2020 at 06:27:31 UTC, Mike Parker wrote: Apparently so. Firefox shows me a 404 for the URL with the parameter ?relatedposts=1. Must be something in the Wordpress settings triggering the fetch. Maybe with Jetpack. I wonder why Chrome doesn't show it. I'll look into it. So it's not happening with every post. And now I've seen that when it does happen, it also returns 404 for the URL with no parameters. I'm also seeing it in Chrome now. The option to show related posts in Jetpack is turned off. So I have no clue why that keeps showing up for some posts and not others.
Re: weekly news?
On Thursday, 23 January 2020 at 06:23:14 UTC, Mike Parker wrote: I'm not getting any 404s in the network tab in Chrome's dev tools. Even on a reload. Most everything is 200, with a handful of 204s. A couple are 302 or 304, and there's one 101. Am I missing something? Apparently so. Firefox shows me a 404 for the URL with the parameter ?relatedposts=1. Must be something in the Wordpress settings triggering the fetch. Maybe with Jetpack. I wonder why Chrome doesn't show it. I'll look into it.
Re: weekly news?
On Thursday, 23 January 2020 at 00:58:10 UTC, Adam D. Ruppe wrote: On Thursday, 23 January 2020 at 00:52:10 UTC, Mike Parker wrote: Got any examples? No one has reported this to me before and I haven’t encountered a 404 in a while. Almost all of them! Hit F12 to open browser tools and notice the network tab: https://dlang.org/blog/2020/01/08/recent-d-compiler-releases/ https://dlang.org/blog/2020/01/04/dconf-2020-double-decker-edition/ and more. The HTML is displayed, but it has the 404 code so according to the http spec you are actually displaying it all as error pages! I'm not getting any 404s in the network tab in Chrome's dev tools. Even on a reload. Most everything is 200, with a handful of 204s. A couple are 302 or 304, and there's one 101. Am I missing something?
Re: weekly news?
On Wednesday, 22 January 2020 at 23:08:09 UTC, Russel Winder wrote: On Wed, 2020-01-22 at 22:48 +, Mike Parker via Digitalmars-d-learn wrote: […] To D Blog has an RSS feed: http://dlang.org/blog/index.php/feed/ […] This URL doesn't seem to work for me. It redirects to: https://dlang.org/blog/feed/ which gives "file not found" For me, the first link redirects to: http://feeds.feedburner.com/OfficialDBlog
Re: weekly news?
On Wednesday, 22 January 2020 at 23:23:41 UTC, Adam D. Ruppe wrote: Several pages on the official blog give code 404 even though they work. Your RSS reader probably just isn't checking the code, but the browser is. These should all be fixed on the server... could be hurting seo too. Got any examples? No one has reported this to me before and I haven’t encountered a 404 in a while.
Re: weekly news?
On Wednesday, 22 January 2020 at 18:53:49 UTC, mark wrote: Is there a "D weekly news" I could do an email subscription to? Or at least a way to get notified by email when a new item appears on https://dlang.org/blog/ ? This Week in D linked above is great for a weekly summary. To D Blog has an RSS feed: http://dlang.org/blog/index.php/feed/ All D Blog posts are automatically shared on Twitter and Facebook: https://twitter.com/D_Programming https://www.facebook.com/dlang.org/ Info on subscribing to the newsgroups and mailing lists is available at: https://www.digitalmars.com/NewsGroup.html You’ll want digitalmars.D.announce for the Announce forum. All thread-starting posts in Announce also go to the DLang Newsfeed Twitter: https://twitter.com/dlang_ng
Re: Some comments on learning D using the tour
On Wednesday, 15 January 2020 at 20:06:01 UTC, mark wrote: However, what I really miss is a contents page so that I can look at each topic and jump back when I want to recap something. Please submit an enhancement request: https://github.com/dlang-tour/core/issues For example, I haven't found one definitive place in the docs that document D's strings. https://dlang.org/spec/arrays.html#strings
Re: books for learning D
On Monday, 13 January 2020 at 11:58:51 UTC, mark wrote: Both those books are published by Packt who normally have no quality control at all as I've discovered to my cost. However It's hit and miss in my experience. I've picked up some utter crap from them, but I've also found some real gems. There's no real vetting of the authors they sign, so the writing quality and knowledge level vary. Assuming those are up to snuff, much depends on feedback from the technical reviewers and the author's ability to evaluate the editor's revisions. Packt's editors follow a rote process where certain words and phrases are *always* replaced from a set of alternatives and certain phrases are *always* inserted in certain circumstances (e.g., to introduce a code snippet) without any regard for the surrounding context. Fortunately, they give the author a chance to review the edits before publication. In my case, they were willing to accept my revision of the revisions (the ones I caught, anyway). Sadly, I never had a chance to do the same with the two chapters they published online. I can attest that Adam's and Kai's books are worth the buy. I own and have enjoyed both. If either of them were to do a 2nd edition, I'd pick it up!
Re: Win32 Api: How create Open/"Save as" Dialog?
On Friday, 10 January 2020 at 15:06:07 UTC, Marcone wrote: Very complicated. Can you send me the simple clear code? https://docs.microsoft.com/en-us/windows/win32/dlgbox/using-common-dialog-boxes
Re: Default values in derived class
On Saturday, 28 December 2019 at 20:22:51 UTC, JN wrote:
import std.stdio;
class Base
{
bool b = true;
}
class Derived : Base
{
bool b = false;
}
void main()
{
// 1
Base b = new Derived();
writeln(b.b); // true
// 2
Derived d = new Derived();
writeln(d.b); // false
}
Expected behavior or bug? 1) seems like a bug to me.
Expected. Member variables do not override base class variables.
b is declared as Base, so it knows nothing about Derived’s member
variable even though you instantiated it with an instance of
Derived. There’s no vtable for variables. If you want it to print
false, then you either have to cast b to Derived or provide a
getter function in Base that Derived can override.
Re: What kind of Editor, IDE you are using and which one do you like for D language?
On Wednesday, 25 December 2019 at 10:57:45 UTC, Ron Tarrant wrote: On Tuesday, 24 December 2019 at 16:43:06 UTC, Mike Parker wrote: But now that VS Code's performance is within my tolerance range Just curious what you mean by this, Mike. For a while, typing in VS Code was clunky compared to Sublime. I gave it a spin every couple of months to see how it was shaping up and eventually I stopped noticing the difference.
Re: What kind of Editor, IDE you are using and which one do you like for D language?
On Monday, 23 December 2019 at 20:45:53 UTC, TheGag96 wrote: I've loved Sublime for years. I use it for everything, really. So pretty, so fast. I really like Sublime, too. Paid for it. But now that VS Code's performance is within my tolerance range, the built-in console makes the difference. I've got the Terminal plugin for Sublime that allows you to press ctrl-shift-alt-t to open the terminal in the project folder, but it just isn't the same experience. I still use Sublime when I just need a quick edit or single file. Otherwise, VS Code has become my goto editor for any multi-file D, Markdown, HTML, etc., project.
Re: array of functions/delegates
On Tuesday, 24 December 2019 at 13:13:12 UTC, MoonlightSentinel
wrote:
On Tuesday, 24 December 2019 at 10:40:16 UTC, Mike Parker wrote:
struct S {}
void f1(S s) {}
void f2(S s) {}
alias Func = immutable(void function());
immutable Func[2] funcs = [cast(Func), cast(Func)];
Though, it's not clear to me wy the one requires casting the
pointer type and the other doesn't.
Because typeof() == void function(S)
Right. I didn't modify the alias declaration when I took the
functions out of the struct. I saw the immutable in the error
message and thought that was the problem.
alias Func = void function(S);
Re: Static linking, specifying binary and test-library folder
On Tuesday, 24 December 2019 at 05:51:37 UTC, Adnan wrote: Hello, how does one: 1. Force static linking (build with `-defaultlib` flag) Generally, when you don't see a buildOption in the docs for the compiler flag you want, use dflags. https://dub.pm/package-format-json.html 2. Specify binary file generated by the `dub buid` command targetPath, described under Build Settings in the docs. 3. Specify binary file generated by the `dub test` command You can override some of the settings for the build types (like the unittest build type), but targetPath is not one of them. https://dub.pm/package-format-json.html#build-types I would try to do it using a configuration. Name it whatever you want (perhaps "testing"). Set the targetPath in the configuration block, then run: dub -ctesting test https://dub.pm/package-format-json.html#configurations
Re: array of functions/delegates
On Tuesday, 24 December 2019 at 07:37:02 UTC, Rumbu wrote:
I am trying to create an array of functions inside a struct.
struct S {
void f1() {}
void f2() {}
alias Func = void function();
immutable Func[2] = [, ]
}
What I got: Error: non-constant expression ''
Tried also with delegates (since I am in a struct context but I
got: no `this` to create delegate `f1`.
So, is there any way to have an array of functions without
adding them at runtime?
This isn't an array of functions you're creating here. A pointer
to a member function is *always* a delegate, unless the function
is static. Pointers to functions can be known at compile time, so
this works:
struct S () {
static void f1() {}
static void f2() {}
alias Func = void function();
immutable Func[2] funcs = [, ];
}
As does this:
struct S {}
void f1(S s) {}
void f2(S s) {}
alias Func = immutable(void function());
immutable Func[2] funcs = [cast(Func), cast(Func)];
Though, it's not clear to me wy the one requires casting the
pointer type and the other doesn't.
Re: unicode characters are not printed correctly on the windows command line?
On Sunday, 22 December 2019 at 06:25:42 UTC, rikki cattermole wrote: On 22/12/2019 7:11 PM, moth wrote: is there any function i can call or setting i can adjust to get D to do the same, or do i have to wait for something to be fixed in the language / compiler itself? Not a bug. This is a known issue on the Windows side for people new to developing natively for it. Yes, and it's not just D programs. And setting the code page isn't always perfect, as it matters which font cmd is configured to use. Google for "windows command prompt unicode output". MS has updated the command prompt to support Unicode, but I don't know how to use it: https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/ If you're on Windows 10, there's also Windows Terminal, which was released on the app store in June: https://devblogs.microsoft.com/commandline/windows-terminal-preview-v0-7-release/
Re: How to create a custom max() function without the ambiguity error.
On Friday, 6 December 2019 at 21:02:53 UTC, realhet wrote: Here's my latest attempt on EXTENDING std.algorithm.max's functionality with a max operation on a custom type. The type is the GLSL vec2 type which does the max operation component-wise. The D std implementation uses the < operator, but with overriding that for my custom type it is impossible to realise. -> max(vec2(1, 2), vec2(2,1)) == vec2(2,2) The reason you're having so much trouble with this is that you're violating the contract of max. It's a template, so it's already set up to work with custom types without any need to write a custom max function, as long as the types adhere to the contract. Consider other functions in std.algorithm, such as sort or equal, that allow you to pass a custom predicate. max doesn't have that because, by defintion, there is only one comparison for it to do: >. Any type that doesn't support that isn't going to work with max. Moreover, your return value violates the function's contract: "Iterates the passed arguments and return the maximum value." You aren't returning the maximum value. You're returning a new value constructed from the maximum components of the two parameters. That is not the same behavior as max(1, 3). Given that your function has a different contract, it should also have a different name.
Re: Unexpectedly nice case of auto return type
On Tuesday, 3 December 2019 at 10:06:22 UTC, Mike Parker wrote: On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote: That's interesting details of D developement. Since you reply to the first message I think you have not followed but in the last reply I told that maybe we should be able to name the type of null. I think this relates to TBottom too a bit. https://github.com/dlang/DIPs/blob/40352337053998885fbd0fe2718c300a322d3996/DIPs/DIP1NNN-DK.md Ah, well. I meant to post the link to the PR: https://github.com/dlang/DIPs/pull/172
Re: Unexpectedly nice case of auto return type
On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote: That's interesting details of D developement. Since you reply to the first message I think you have not followed but in the last reply I told that maybe we should be able to name the type of null. I think this relates to TBottom too a bit. https://github.com/dlang/DIPs/blob/40352337053998885fbd0fe2718c300a322d3996/DIPs/DIP1NNN-DK.md
Re: Exceptions on Windows being "swallowed"
On Wednesday, 27 November 2019 at 05:15:10 UTC, cartland wrote: No MS installed. Just using DMD. - dub -a x86_mscoff --force -v : So please try it without dub dmd -m32mscoff x.d If that works, add some debug flags like dub does: dmd -m32mscoff -debug -g x.d And see what happens.
Re: Exceptions on Windows being "swallowed"
On Wednesday, 27 November 2019 at 02:48:53 UTC, cartland wrote:
Trying out exception handling. When an exception occurs,
program seems to just exit.
dub -a x86_mscoff
I compiled it with dmd and ran it directly from the command line
and it worked fine:
C:\dev\D\scratch>ex
finally
catch %sfirst
done
Did you try that? And do you have the MS linker installed or are
you using the lld that ships with DMD?
Two things regarding your code:
writeln does no formatting. You want writefln for that. But with
writeln, you can provide multiple string arguments and they will
be concatenated into the final output, like this:
writeln("catch ", e.msg);
Also, you don't need the `int main` signature if you don't
actually need the return value to signify anyting:
void main() { }}
is just fine.
Re: how to implement a function in a different D source file
On Tuesday, 26 November 2019 at 03:55:24 UTC, mipri wrote:
On Tuesday, 26 November 2019 at 03:06:52 UTC, Omar wrote:
the page here https://dlang.org/spec/function.html
suggests you can implement a function in a different file
...
mentioned the endeavour of no-bodied-functions as a way of
presenting a black-box type of interface.
oh, that's what you were asking.
Consider:
$ cat interface/references.d
module references;
string greeting();
$ cat implementation/references.d
module references;
string greeting() {
return "Hello, Dave";
}
$ cat main.d
import references;
void main() {
import std.stdio: writeln;
writeln(greeting);
}
And trying to build it:
$ dmd -c implementation/references.d
$ dmd -Iinterface -c main.d
$ dmd main.o references.o
$ ./main
Hello, Dave
The idiomatic way to do that is to put the interface in a "D
interface" file (.di) and the implementation in a .d file:
foo/bar.di
foo/bar.d
Then, when importing foo.bar, the compiler will pick up the .di
file automatically.
And you can actually have the compiler generate the interface
file for you from a source file with the -H option.
Re: How to simulate Window's "Press any key to continue..."
On Friday, 22 November 2019 at 04:45:21 UTC, Mike Parker wrote:
On Friday, 22 November 2019 at 04:22:07 UTC,
FireController#1847 wrote:
Right, but readln will only wait until the user presses the
delimiter (by default Enter/Return). I want it to wait until
ANY key is pressed, not a specific key
The documentation for std.stdio.File shows two functions for
reading input: readln and readf. If readln isn't what you want,
then readf probably is:
https://dlang.org/phobos/std_stdio.html#.File.readf
Also, there's a freely available book online to help get you up
to speed: Programming in D. Here's the section on reading from
stdin with readf:
http://ddili.org/ders/d.en/input.html
Sorry, I just noticed the book doesn't cover how to do what you
want and it's probably not obvious. You need to call readf with a
character format string (%c):
import std.stdio;
void main()
{
writeln("Press any key to continue...");
char c;
readf("%c", );
writeln("Thanks!");
}
Re: How to simulate Window's "Press any key to continue..."
On Friday, 22 November 2019 at 04:22:07 UTC, FireController#1847 wrote: Right, but readln will only wait until the user presses the delimiter (by default Enter/Return). I want it to wait until ANY key is pressed, not a specific key The documentation for std.stdio.File shows two functions for reading input: readln and readf. If readln isn't what you want, then readf probably is: https://dlang.org/phobos/std_stdio.html#.File.readf Also, there's a freely available book online to help get you up to speed: Programming in D. Here's the section on reading from stdin with readf: http://ddili.org/ders/d.en/input.html
Re: csvReader & specifying separator problems...
On Thursday, 14 November 2019 at 12:25:30 UTC, Robert M. Münch
wrote:
From the docs, which I find extremly hard to understand:
auto csvReader(Contents = string, Malformed ErrorLevel =
Malformed.throwException, Range, Separator = char)(Range input,
Separator delimiter = ',', Separator quote = '"')
Contents, ErrorLevel, Range, and Separator are template (i.e.
compile-time) parameters. Input, delimiter, and quote are
function (i.e. runtime) parameters.
So, let's see if I can decyphre this, step-by-step by trying
out:
csv_records = csv_data.csvReader();
Here, you aren't providing any template parameters and only the
first function parameter, so it's the equivalent to calling the
function like so:
csvReader!(string, Malformed.throwException, typeof(csv_data),
char)(csv_data, ',', '"');
Which indicates some problem because not all fields are set in
my CSV data. So let's ignore any error by specifying
Malformed.ignore;
csv_records = csv_data.csvReader(Malformed.ignore);
csv_records = csv_data.csvReader!(string, Malformed.ignore)();
The docs state Malformed as 2nd parameter, since I use UFCS I
assume that this becomes the first parameter. I don't
Malformed is the 2nd template parameter, your UFCS value is the
first function parameter.
understand what the 3rd parameter (Range) is about.
Range is the type of the first parameter. It's common outside of
Phobos use T and U for template types, but any valid symbol name
can be used. This template has three type parameters which are
named according to their purpose (Contents, Range, and
Separator). Since Range is also the type of the first function
parameter, the compiler will infer the type if you don't specify
it.
4th parameter is my separator, which I need to set to ';'
somehow.
The fourth _template_ parameter is the _type_ of your separator
(and is set to default to char) not the actual separator. You
want to set the delimiter, which is the second _function_
parameter.
csv_records = csv_data.csvReader!(string, Malformed.ignore)(';');
Re: How to import & export modules
On Monday, 11 November 2019 at 01:28:54 UTC, userTY wrote: import all; // can see App, Form and Button exported (public) symbols --- The approach of using an "all" module is an old hack that is no longer necessary. Today, the way to approach is to use a "package module". https://dlang.org/spec/module.html#package-module Given a package "mylib" containing multiple modules, create a file "mylib/package.d". Use the package name as the module name and follow it with your public imports: module mylib; public import mylib.foo, mylib.bar, mylib.baz; Then users of the package can simply: import mylib;
Re: A question about postblit constructor
On Tuesday, 5 November 2019 at 10:32:03 UTC, Ferhat Kurtulmuş wrote: On Tuesday, 5 November 2019 at 10:31:05 UTC, Ferhat Kurtulmuş wrote: On Tuesday, 5 November 2019 at 10:13:59 UTC, Mike Parker wrote: [...] Yep, it is obvious that my code is wrong. s1 and s2 point to the same memory address. I could obtain my desired behavior with copy constructor. The documentation also say "WARNING: The postblit is considered legacy and is not recommended for new code. Code should use copy constructors defined in the previous section". I meant the example as an answer to your statement, "I wonder how new memory is allocated without an explicit malloc here". The postblit was intended as a chance to "fixup" everything when you needed a deep copy. The new struct is initialized as a shallow copy, so when you enter into the postblit, the pointer is already pointing at the original location. Without assigning it a new malloc'ed address, your memcpy was essentially overwriting the original location with its own data.
Re: A question about postblit constructor
On Tuesday, 5 November 2019 at 08:47:05 UTC, Ferhat Kurtulmuş wrote: value of int which is 0. I wonder how new memory is allocated without an explicit malloc here. Sorry for this noob question in advance, I could not find any doc mentioning a similar case. int* vals = cast(int*)malloc(len * S.sizeof); vals[0] = 4; vals[1] = 5; S s1 = S(vals, len); S s2 = s1; writeln(s2.vals[0]); writeln(s2.vals); writeln(s1.vals); } https://run.dlang.io/is/D0nfeT
Re: Which is the active fork in DFL gui library ?
On Saturday, 2 November 2019 at 20:01:27 UTC, Vinod K Chandran wrote: Hi all, I just found that DFL gui library very interesting. But after some searching, i can see that DFL is inactive and there is few other forks for it. So this is my question - Which fork is good for a gui development in windows platform. DFL is a long, long dead library. It was created with D1. I'm unaware of any active fork. BTW, i just tested the gtkD and successfully compiled a hello app. How do i avoid the console window when compiling gtkD app ? Thanks in advance. Any Windows executable compiled with a main function is by default considered a "console subsystem" application. You can specify to the linker that it should be a "windows subsystem" application (for which a console window will not be created) with a linker command line switch. Assuming you're using DMD, when you're using the OPTLINK linker (which is the default when invoking DMD directly or when passing -m32, or the DUB switch -ax86), the switch is /SUBSYSTEM:WINDOWS. You can pass it on the DMD command line with -L, as in: -L/SUBSYSTEM:WINDOWS With the Microsoft linker (-m32mscoff or -m64 on the dmd command line, -ax86mscoff or -x86_64 with dub, or the default with recent 64-bit dub versions), it's the same switch. But you also need to specify the entry point as being main and not WinMain, so: -L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTStartup When using dub, you can put the appropriate flags in a "dflags" entry in your dub.json or dub.sdl. Here's an example, winhello.d, that should work with all of the following command lines: dub -ax86 --single winhello.d dub -ax86_mscoff --single winhello.d dub -ax86_64 --single winhello.d dmd -L/SUBSYSTEM:WINDOWS winhello.d dmd -L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTstartup -m32mscoff winhello.d dmd -L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTstartup -m64 winhello.d If you don't have the Microsoft build tools installed, -m32mscoff and -m64 will use the lld linker that ships with DMD (if you chose to install it when you installed dmd). In that case, I'm not sure if the switches are the same. I've never used it and don't have it installed.
Re: Which is the active fork in DFL gui library ?
On Sunday, 3 November 2019 at 07:06:12 UTC, Mike Parker wrote:
Here's an example, winhello.d, that should work with all of the
following command lines:
Sorry, here's the example:
== winhello.d
/+ dub.sdl:
name "entry"
dflags "-L/SUBSYSTEM:WINDOWS" "-L/ENTRY:mainCRTStartup"
platform="windows-dmd"
+/
import core.sys.windows.windows;
pragma(lib, "user32");
void main() {
MessageBoxA(null, "Hello", "Hello", MB_OK);
}
Re: D for sciencetific scripting / rapid protoryping
On Tuesday, 22 October 2019 at 07:40:01 UTC, Prokop Hapala wrote: 1) I'm not speaking about OpenGL and SDL specifically (that was just small example which I tried first) FYI, the BindBC bindings can be configured as dynamic (in which all the of C library functions are declared as function pointers and the C shared library must be loaded manually at runtime) or static (in which the C library functions become normal function declarations with no implementation and there is a link-time dependency on the C static or shared library). The exception is OpenGL, for which there is no static binding. The dynamic bindings add the overhead of the function pointer declarations when linked. It's insignificant for most of them. The biggest bindbc-opengl, depending on how many extensions you configure (it's extremely high for DerelictGL3 most of the time, as it tends to pull in more extensions). 2) I'm more concerned about how to D compiler links dependencies when it compiles simple .d program (with lot of dependencies). When using dub, it depends on the package configuration of each dependency. All of the Derelict and BindBC packages, for example, are configured to build as static libraries. It didn't (and doesn't) make sense to me to compile a binding as a shared library. Dub packages can also be configured as shared libraries, or simply as "library" (I haven't investigated what that means). Some might provide custom subconfigurations to choose static or shared. The biggest overhead with DMD output tends to come from the standard library. On Windows, the static library the only option. IIRC on Linux it's necessary to pass -defaultlib=libphobos2.so to DMD to link the shared lib. I don't know how LDC handles it.
Re: Any 3D Game or Engine with examples/demos which just work (compile) out of the box on linux ?
On Saturday, 19 October 2019 at 00:57:48 UTC, Prokop Hapala wrote: The dmech/demos also seems to be almost running just it somehow cannot find or use my libsdl.so library which it just compiled (it is in 'dmech/demos/lib') derelict.util.exception.SharedLibLoadException@derelict/util/exception.d(43): Failed to load one or more shared libraries: ./lib/libsdl.so - ./lib/libsdl.so: wrong ELF class: ELFCLASS32 The problem is there in the error message. You have a 32-bit version of SDL, but you're compiling a 64-bit app. You need the 64-bit SDL.
Re: Struct initialization has no effect or error?
On Thursday, 3 October 2019 at 04:57:44 UTC, mipri wrote:
On Thursday, 3 October 2019 at 04:33:26 UTC, Brett wrote:
I was trying to avoid such things since X is quite long in
name. Not a huge deal... and I do not like the syntax because
it looks like a constructor call.
It is a constructor call, though. You can define your own as
well:
Technically it's a struct literal. It's only a constructor if you
define one, in which case struct literals no longer work. E.g.,
struct Foo {
int x;
this(int a, int b) { x = a + b; }
}
Without the constructor, the literal Foo(10) would be valid, but
with the constructor you'll get a compiler error.
Re: Why is it difficult to reference arrays in structs?
On Thursday, 3 October 2019 at 04:32:52 UTC, Brett wrote:
Ok, fine!
auto r =
Now r is a reference, great!
No, r is a pointer, not a reference. D does not have reference
variables.
But now the semantics of using the array completely change and
errors abound!
Probably because you're trying to use r as if it were of type Y[]
when it's really of type Y[]*, i.e. if you wanted to append to it
you would need to first dereference the pointer:
*r ~= Y(10.0);
Normal D pointers tend to act very nice, e.g., we don't have to
use the C++ -> BS
But with arrays it seems things are all screwed up and do not
work correctly.
No, they're working as intended.
I can't just use r like I used x.a. I can't even use *r as
things then get even more screwed up.
Appending to *r works as expected:
https://run.dlang.io/is/IQa619
What sort of trouble did you encounter?
I want to have a slice of an array that I can append to as a
sort of temporary and have it append to the main array(the end
of the slice always is the end of the main array)..
Your issue has nothing to do with structs.
As per the documentation:
https://dlang.org/spec/arrays.html#slicing
the initialization of b here creates a slice referencing a:
int[] a = [0, 1, 2];
int[] b = a;
As a slice, b has its own .ptr and .length properties that are
distinct from those of a. They are initialized with the values of
a's properties, but they *are not references* to a's properties
and b is *not a reference* to a.
assert(b.ptr == a.ptr);
assert(b.length == a.length);
Because b.ptr and a.ptr point to the same memory, any updates to
existing array elements through one will be reflected in the
other:
a[1] = 3;
writeln(b); // prints [0, 3, 2]
But any changes to the .ptr or .length of one will not be
reflected in the other:
a ~= 10;
assert(a.length == 4);
assert(b.length == 3);
writeln(a); // prints [0, 3, 2, 10];
writeln(b); // prints [0, 3, 2];
Though at this point, depending on whether or not a reallocation
took place, they might still be pointing to the same block of
memory.
I've tried assumeSafeAppend but it does nothing to help.
assumeSafeAppend is for telling the runtime that you want to
reuse an existing memory block backing an array and there's no
need to reallocate it in append.
https://dlang.org/articles/d-array-article.html#slice-members-appender
The reason is because i have an algorithm that generates data
and stores it in an array > and it is more efficient and easier
to code if I can just append data to a "slice" of the
array(there are no issues with overwriting).
Essentially it just acts as an alias.
By using pointers it would work but it screws up the entire
syntax of all the code and > then still doesn't work.
Could you adjust the signature of your algorithm to take the
array by ref?
void myAlgo(ref Y[] arr) {
arr ~= Y(10.2);
}
Or to take x by ref (or as a pointer) and manipulate the array
directly:
void myAlgo(ref X x) {
x.a ~= Y(10.2);
}
Re: want to know precise GC benchmarks
On Tuesday, 1 October 2019 at 16:24:49 UTC, a11e99z wrote: why I want to know such info? CodinGame sometimes use time-limit for bot move for example 100ms, and bot will be disqualified in case no answer Simple solution: don't allocate every frame. The GC only runs when it needs to and it only needs to if an allocation request takes it over a certain threshold. If you need to allocate at all, do it up front. Or better, do it statically. Then the GC won't run at all. What sort of CodinGame bot would you need to allocate from the GC for anyway?
Re: Help making a game with transparency
On Saturday, 28 September 2019 at 13:41:24 UTC, matheus wrote: Ok, I took a look over my old projects and I found exactly what you want, by the way it's from 2012. It uses Derelict 2.0 bindings and will draw a PNG image where you can move around with cursor keys. Murilo, if you do decide to use this example as a basis for your project, please don't use DerelictSDL2. I'm not maintaining it anymore. bindbc-sdl, which I linked in my previous post, is what you should prefer. The API to load the library and handle errors is different, but the SDL API calls will all be the same.
Re: Help making a game with transparency
On Friday, 27 September 2019 at 22:55:22 UTC, Murilo wrote: Ahhh, that clears everything up. I will then leave the program without the transparency and wait until you get around to implement the fixes to it, I am not a developer, I am a scientist, I only use libraries, I don't know how to make them properly. You might consider using SDL and SDL_image: https://libsdl.org/download-2.0.php https://www.libsdl.org/projects/SDL_image/ D bindings for both are available here: https://code.dlang.org/packages/bindbc-sdl You don't actually *need* SDL_image, as core SDL can load images in the BITMAP format, and you can then use the API to create transparency from a specific color. But if you want to load PNG files with alpha, you'll want SDL_image. There are numerous tutorials online for SDL, though if you're searching, make sure to look for SDL 2 tutorials and ignore anything for SDL 1.x. The tutorials will all be in either C or C++, but the SDL API using the D bindings is the same. The Lazy Foo tutorials are often recommended: https://lazyfoo.net/tutorials/SDL/ But again, these are C++, so you have to consider the differences in D and C++ when porting the code over. For example, he uses class destructors to free resources. Do that in D and you'll run into trouble. So just ignore how he structures his programs and focus on the main concepts of using SDL: how to acquire/release resources, how to render, etc. You can adapt that to any architecture you want. There's no need for classes at all, for example. Some tutorials out there will show you how to use SDL with OpenGL. Please ignore those. SDL's 2D Rendering API is what you want when you're learning, so focus on tutorials tat show you how to use it. The SDL Wiki has API documentation: http://wiki.libsdl.org/APIByCategory
Re: Indexed graphics for retro engine?
On Thursday, 19 September 2019 at 18:25:05 UTC, Shadowblitz16 wrote: I wanted to do 4bpp 16 color graphics. and I didn't want to load anything unnecessary in the image like the palette but instead supply it myself as a Color[16]; I see. In that case, I suggest you find some tutorials on software rendering in C or C++ and adapt them to D. Most of the modern stuff out there is going to be targeting 24-bit or 32-bit graphics. You might find some older tutorials on indexed 8-bit rendering that you can adapt to 4-bit. Nothing to it but storing the palette indices in a byte array.
Re: combining libraries into 1 or 1 for each system?
On Thursday, 19 September 2019 at 18:28:25 UTC, Shadowblitz16 wrote: I mean I don't want to have multiple dependency dll's but instead just my own dll with the dependencies packed inside. of course dll is only for windows so I would like this done for mac and linux too Then statically link all your dependencies.
Re: Indexed graphics for retro engine?
On Thursday, 19 September 2019 at 03:47:05 UTC, Shadowblitz16 wrote: Is there a way to make a indexed graphics library that can handle importing and exporting true color images? I don't see why not. I would guess something like this could be simulated with pointers and references right? If you want to, say, take a 24-bit or 32-bit and treat it as an 8-bit image, you'll probably want to actually do a conversion rather than a simulation. In which case you'd probably be better off just using an existing C library like FreeImage. You can find a binding here: https://github.com/BindBC/bindbc-freeimage Otherwise, you'll want to hit up a graphics programming forum for resources on image conversion. Two possibilities: https://www.reddit.com/r/GraphicsProgramming/ https://www.gamedev.net/forums/forum/5-graphics-and-gpu-programming/
Re: combining libraries into 1 or 1 for each system?
On Thursday, 19 September 2019 at 03:44:28 UTC, Shadowblitz16 wrote: let's say I have a project the relies on multiple packages.. is it possible to combine these libraries into a single one (or 1 per os) for final shipment of a program? I assume you're referring to dub packages, in which case any dependencies you have will usually be configured to compile as static libraries. That means they'll be compiled into the executable without any extra effort on your part. If they're configured as dynamic libraries, you'll need to ship the dynamic library with your executable or manually edit the configurations to compile as static libraries. If they're bindings to C libraries, you'll need to ship the C dynamic libraries unless you statically link them. If none of this answers your question, please clarify what you mean by "multiple packages".
Re: Make executable archive just like Java's .jar archive?
On Thursday, 12 September 2019 at 12:53:27 UTC, BoQsc wrote: On Thursday, 12 September 2019 at 12:52:48 UTC, BoQsc wrote: Is there a way to archive multiple .d source code files and make that archive executable, or something similar? https://en.wikipedia.org/wiki/JAR_(file_format) A JAR file is just a standard zip file. The Java Virtual Machine loads .class files (which are Java bytecode files, not Java source) and executes them at runtime. It doesn't matter if they're in a jar file or not. Java was designed for this from the beginning. If you're really talking about loading .d *source* files, that means they either have to be interpreted like a scripting language, in which case you'll need a D interpreter, or they'll need to be compiled at runtime into bytecode (in which case you'll need a bytecode interpreter), or compiled at runtime into object files, in which case you'll need a mechanism for loading object files into a program (there was an object loader library around back in the D1 days). If you want to do what Java does and compile ahead of time to a bytecode format and distribute the bytecode in an archive to be loaded at runtime, then that requires implementing a bytecode compiler, a loader, and a bytecode interpreter. I know that LLVM can output bytecode, so with LDC that's the first step out of the way. Now all you need is for someone to implement a loader and bytecode interpreter.
Re: Using CSS Data from Within My Code
On Thursday, 12 September 2019 at 11:40:33 UTC, Ron Tarrant wrote:
string myCSS = "tab { background-color: #f2f2f2; }";
enum will work just as well here and without the need for the
variable:
enum myCSS = "tab { background-color: #f2f2f2; }";
The original error was because q strings have to be valid D, not
because of the enum.
Re: Blog Post #69: TextView and TextBuffer Basics
On Tuesday, 10 September 2019 at 08:29:59 UTC, Ron Tarrant wrote: This morning's discussion covers the basic workings and relationship between the TextView and TextBuffer widgets. Here's the link: https://gtkdcoding.com/2019/09/10/0069-textview-and-textbuffer.html Seriously impressed that you're able to keep this up so consistently. Keep on trucking!
Re: Old code no longer working on any DMD compilers
On Friday, 6 September 2019 at 05:59:30 UTC, Jamie wrote: time and fmod is called so it breaks. In case 3, with default struct arguments, I thought that the constructor I have defined was being called, however the default constructor was being called (this()) so fmod wasn't being called. The reason why my old code worked was because it used the default arguments and I wasn't actually calling the constructor I defined. When I removed the default arguments in the constructor and tried case 2 it obviously didn't work. Am I understanding correctly? Thanks You're right about case 1 and case 2, and partially correct about case 3. Structs don't actually have default constructors. They have default *initializers*. In other words, s = S() is the same as s = S.init. See item #4 in the documentation for struct destructors [1]: "If the ParameterList is empty, the struct instance is default initialized." So yes, your constructor is not being called. 1. https://dlang.org/spec/struct.html#struct-constructor
Re: Is there has an pdf document for Phobos.
On Wednesday, 4 September 2019 at 12:24:47 UTC, lili wrote: On Wednesday, 4 September 2019 at 04:21:10 UTC, Mike Parker wrote: On Wednesday, 4 September 2019 at 03:07:18 UTC, lili wrote: Hi: For some reason it too slow that some times i visited dlang.org, Can admin make a pdf document for download. Documentation is installed with the compiler. How to open it? If you're on Windows, it's located in dmd2/html. I don't know where it's installed on other platforms and I assume it depends on which installation method you used.
Re: Is there has an pdf document for Phobos.
On Wednesday, 4 September 2019 at 03:07:18 UTC, lili wrote: Hi: For some reason it too slow that some times i visited dlang.org, Can admin make a pdf document for download. Documentation is installed with the compiler.
Re: Why is sformat and formattedWrite (appender) allocating GC mem here?
On Saturday, 31 August 2019 at 12:07:56 UTC, cc wrote: And what, if anything, can I do to avoid it? import core.stdc.stdio : printf; There are no @nogc versions of the Phobos write* and format functions.
Re: Input/Output multiple values from function
On Wednesday, 28 August 2019 at 04:19:49 UTC, Jabari Zakiya wrote:
I have a function (say func1) that takes 1 input value (an
integer number) and outputs 4 values (2 integers and 2 arrays
of integers).
Then inside another function (say func2) I provide the 1 input
to func1 and then want to assign its 4 output values to their
appropriate final variables that will use them.
Conceptually I want to do below:
func2 { ...; (a, b, c, d) = func1(i) }
I tried using a struct but compiler keeps complaining.
Thanks for help in advance.
A struct should work just fine:
https://run.dlang.io/is/aMBGD0
import std.stdio;
struct Results {
int a, b;
int[] aa, ab;
}
Results func1() {
return Results(1, 2, [0, 1, 2, 3], [10, 11, 12]);
}
void main()
{
writeln(func1);
}
What is the compiler complaining about?
Re: D1: Trying to update Juno Library to 1.076
On Friday, 23 August 2019 at 16:09:16 UTC, jicman wrote: } That looks like D2 code. I am trying to compile D1 code. I think the linker is not getting something right. You might try declaring the offending functions as extern(Windows) function pointers and then loading them from the appropriate DLLs via LoadLibrary/GetProcAddress. I had to do that with some Win32 functions I used back before we got support for COFF and the Windows SDK because, for whatever reason, they were missing from the OMF libs that ship with DMD.
Re: How should I sort a doubly linked list the D way?
On Tuesday, 13 August 2019 at 22:12:23 UTC, Mirjam Akkersdijk
wrote:
Though, it left me with some semi-offtopic questions unanswered:
(1) Ali, do you mean that from an optimization viewpoint, it's
better to keep appending like `nodes ~= ...` instead of setting
the length first? I would like to have some more background on
that claim.
He's not saying it will be better, but that the cost will be
negligible. On every append, the GC allocates new memory only if
the current capacity == 0. When it does allocate, it allocates
more space than it actually needs based on the current length of
the array, so you don't actually have an allocation on every
append. Also, when the adjacent memory block is free and can hold
the additional elements, the allocation consists of extending the
array's memory block and no copying is performed, making the cost
of the allocation even cheaper than it could be.
Anyway, you can use `reserve` when appending rather than setting
the length. This will allocate enough memory without
default-initializing anything and you don't have to worry about
bounds checking.
int[] ints;
ints.reserve(100);
foreach(i; 0..100) {
ints ~= i;
}
See Steve Schveighoffer's array article for details:
https://dlang.org/articles/d-array-article.html
Re: Why is this allowed? Inheritance variable shadowing
On Tuesday, 13 August 2019 at 04:40:53 UTC, Chris Katko wrote:
You can drop this straight into run.dlang.io:
import std.stdio;
class base{ float x=1;}
class child : base {float x=2;} //shadows base variable!
void main()
{
base []array;
child c = new child;
array ~= c;
writeln(c.x); //=2
writeln(array[0].x); //=1 //uses BASE's interface, yes,
//but why does the CHILD instance one exist at all?
}
It appears to be legal C++ as well but I can't imagine a
situation where you'd want to allow the HUGE risk of
shadowing/aliasing variables in an child class. Why is
inheritance shadowing allowed? Especially when in D you have to
explicitly "override" existing _methods_ but not
fields/variables?
To quote a Stack Overflow comment on C++ having this "It's not
a compile error, but it's certainly a design one." Is this
allowed just because "C++ does it" or because it has some sort
of real world use that justifies the risk?
Personally, I'd love a compile-time warning that I could turn
on that flags this situation.
Thanks for your help,
--Chris
I don't know if I'd call that shadowing. This is how it works in
Java, too. There's no such thing as a vtable for member variables
-- each class gets its own set and they don't conflict. The only
time it could be really be called shadowing is when the base
class member is protected, as then it's accessible in the
subclass scope.
Also, it's not the same thing as overriding. Overriding means
that when you call base.foo(), you get sub.foo()'s
implementation. But when you access base.var, you get base.var
and not sub.var.
I would find it extremely annoying if it worked the way you're
expecting it to.
Re: How to contact people on the forum
On Wednesday, 24 July 2019 at 16:37:33 UTC, Greatsam4sure wrote: On Wednesday, 24 July 2019 at 15:56:43 UTC, drug wrote: 24.07.2019 18:51, Greatsam4sure пишет: Good day everyone. I am thinking, if there is a way to contact any person on dlang forums through mail or any other means. How do I get their email from their forum post? I use thunderbird to read the forum and every post contains email of its author, so I would use it to communicate. I don't use thunderbird any other options On the web forum there”s a link labeled “Source” on every post. Click it to see the raw message, including the header which contains the email address. Just be aware that not everyone uses a valid email address.
Re: Why after writeln the binaryHeap become empty?
On Wednesday, 19 June 2019 at 06:00:28 UTC, Jonathan M Davis wrote: On Tuesday, June 18, 2019 10:27:46 PM MDT lili via Do you known reason for why Dlang Range are consumed by iterating over them. I this design is strange. If you want an overview of ranges, you can watch this: https://www.youtube.com/watch?v=A8Btr8TPJ8c You can also read this: http://ddili.org/ders/d.en/ranges.html - Jonathan M Davis And this excerpt from Learning D: https://hub.packtpub.com/understanding-ranges/
Re: What is difference between struct and class?
On Monday, 3 June 2019 at 08:50:46 UTC, Mike Parker wrote: On Monday, 3 June 2019 at 08:47:41 UTC, Mike Parker wrote: If yes, when should one use 'new'? Whenever you need to allocate something from the GC heap. In my experience, it's rare to need it with value types in D. I tend to use it primarily with classes and arrays. Ali's book has an example using a struct-based linked list in the chapter on pointers: https://forum.dlang.org/thread/rkmcvxftykhsvxofp...@forum.dlang.org Wrong link. It's at: http://ddili.org/ders/d.en/pointers.html
Re: What is difference between struct and class?
On Monday, 3 June 2019 at 08:47:41 UTC, Mike Parker wrote: If yes, when should one use 'new'? Whenever you need to allocate something from the GC heap. In my experience, it's rare to need it with value types in D. I tend to use it primarily with classes and arrays. Ali's book has an example using a struct-based linked list in the chapter on pointers: https://forum.dlang.org/thread/rkmcvxftykhsvxofp...@forum.dlang.org
Re: What is difference between struct and class?
On Monday, 3 June 2019 at 07:13:44 UTC, Rnd wrote:
I know 'new' is not needed to create instances of structs but
can one use 'new'?
Yes. It can be used with any value type to allocate a block of
memory on the GC heap and return a pointer to that memory:
struct Foo { ... }
Foo* f = new Foo;
int* i = new int;
If yes, when should one use 'new'?
Whenever you need to allocate something from the GC heap. In my
experience, it's rare to need it with value types in D. I tend to
use it primarily with classes and arrays.
Re: [dub] Passing --DRT-gcopt to dmd
On Friday, 31 May 2019 at 10:27:44 UTC, Anonymouse wrote: What is the correct way? --DRT flags are for run time, not compile time. They're intended to be passed to your executable and not the compiler. From the docs [1]: "By default, GC options can only be passed on the command line of the program to run" With dub, anything following a solitary -- on the command line will be passed to the application [2], so you probably want something like this: dub test -- --DRT-gcopt=profile:1 [1] https://dlang.org/spec/garbage.html#gc_config [2] https://dub.pm/commandline
Re: dmd + optlink Symbol Undefined _StretchDIBits@52
On Thursday, 2 May 2019 at 22:54:20 UTC, Joshua Hodkinson wrote: Hi everyone, I am getting a linker error when compiling with dmd (v2.085.1) when using StrechDIBits from the win32 api. Error 42: Symbol Undefined _StretchDIBits@52 However with ldc (v1.15.0) the program compiles correctly. Wondering if I've missed something here, or possibly identified a bug with dmd? Thanks By default, DMD uses the Optlink linker and some quite old system import libraries in the OMF format. They’re missing a number of functions. If you compile with -m32mscoff for 32-bit or -m64, DMD will use the Microsoft linker and import libraries if you have Visual Studio or the MS Build tools installed, and the LDC linker with some import libraries from MinGW if you don’t.
Re: Packages / imports & references between modules
On Sunday, 28 April 2019 at 11:12:50 UTC, Robert M. Münch wrote:
One more problem now showing up, when I do this:
A/a.d
module A.a;
struct myStruct;
A/b.d
module A.b;
struct myStruct {...}
A/c.d
module A.c;
import A;
struct myOtherStruct {
myStruct ms;
}
I now get an error in file A/c.d that a.a.myStruct conflicts
with a.b.myStruct. Looks like these symbols are different for
D. Is there a way to tell D that one is only a forward
reference and is the same when D sees the struct declaration
later?
They're different symbols because they're in different modules.
The module and package name is part of the symbol name. Just
import A.b in A.a.
Re: DMD different compiler behaviour on Linux and Windows
On Friday, 26 April 2019 at 15:48:51 UTC, Ron Tarrant wrote: On Thursday, 25 April 2019 at 20:38:31 UTC, Mike Parker wrote: If you compile with -m32 on Windows the error goes away. Not trying to be a but it also works with -m64 on Windows. Yes, thanks. That's a typo. -m32, where size_t is uint, is the default. In -m64, size_t is ulong.
Re: DMD different compiler behaviour on Linux and Windows
On Thursday, 25 April 2019 at 20:18:28 UTC, Zans wrote:
import std.stdio;
void main()
{
char[] mychars;
mychars ~= 'a';
long index = 0L;
writeln(mychars[index]);
}
Why would the code above compile perfectly on Linux (Ubuntu
16.04), however it would produce the following error on Windows
10:
source\app.d(8,21): Error: cannot implicitly convert expression
index of type long to uint
On both operating systems DMD version is 2.085.0.
DMD defaults to 64-bit output on 64-Bit Linux but always to
32-bit output on Windows, If you compile with -m32 on Windows the
error goes away. Reasons::
* Array indices are default typed as size_t, which is uint in
32-bit and ulong in 64. long is not implicitly convertible to
uint.
* On Linux, both 64- and 32-bit builds of DMD are available and
the output for each defaults to the same. Only the 32-bit build
is distributed on Windows.
* Historically, compiling 64-bit binaries on Windows required a
separate installation of the Microsoft Build Tools ( or Visual
Studio) and/or the Windows SDK. If 64-bit output were the
default, DMD would not work out of the box. Recently, DMD has
been shipping with the lld linker and some MinGW-based Windows
libraries so that the additional installation is not required and
64-bit compiles can work out of the box, but it’s still
considered experimental.
When out-of-the-box 64-bit compilation is solid and 64-bit builds
are distributed on Windows, the default behavior should be the
same as on Linux.
Re: Check if function argument can be handled in CT
On Wednesday, 24 April 2019 at 10:52:58 UTC, Andrey wrote:
On Wednesday, 24 April 2019 at 08:28:06 UTC, Basile.B wrote:
On Wednesday, 24 April 2019 at 07:53:47 UTC, Andrey wrote:
I know about this template. Unfortunally, it doesn't work
inside functions.
void test(string arg1, string arg2)
{
enum isKnown1 = is(typeof((){enum v = arg1;}));
enum isKnown2 = is(typeof((){enum v = arg2;}));
writeln(isKnown1);
writeln(isKnown2);
}
void main()
{
test("qwerty", "qaz");
}
Output:
false
false
And I don't want to execute function using CTFE. The function
should be ran as usual.
Example:
char[] test(string arg1, string arg2)
{
static if(isCTArg(arg1) && isCTArg(arg2))
{
enum result = "CT: " ~ arg1 ~ " and " ~ arg2; // no
allocations
return result;
}
else
{
import std.format : format;
auto result = format!"RT: %s and %s"(arg1, arg2); //
at least 1 allocation
return result;
}
}
void main()
{
// ...
auto val = test(some_CT_or_RT_arg1, some_CT_or_RT_arg2);
// not CTFE.
// ...
}
arg1 and arg2 are *never* compile-time arguments. If a function
is executed at compile time, the function may be passed arguments
that are compile-time values, but inside the function, the
arguments are interpreted as if it were running at runtime. That
means that you can't assign function arguments to enums.
Re: Anyone have a Vibe.d Diet Template syntax definition for Sublime?
On Monday, 22 April 2019 at 04:12:11 UTC, Andrej Mitrovic wrote: Or perhaps for any other editor so I could adapt it and have syntax highlighting in Sublime when viewing .dt files. Bot dls and code-d have VS Code syntax files for diet templates: https://github.com/d-language-server/vscode-dlang/tree/master/syntaxes https://github.com/Pure-D/code-d/tree/master/syntaxes
Re: bug in compiles?
On Thursday, 11 April 2019 at 22:41:32 UTC, Alex wrote: Seriously? Do you think you have ESP? Your code isn't even close to was talking about ;/ Here is is updated that shows the error. You seem to fail to understand that it is impossible for it to be my code. If you continue to attack people who are trying to help you, the moderators will stop approving your posts. The hostility is unwelcome here. If the number of your posts that have not been approved didn’t serve as a warning, then this does.
Re: Templates - What's Up with the template keyword?
On Tuesday, 9 April 2019 at 10:53:49 UTC, Ron Tarrant wrote:
On Monday, 8 April 2019 at 14:56:46 UTC, Mike Parker wrote:
In the subsequent sections, I show both long and short
(eponymous) forms of enum and function templates.
In your book, Mike, you stated:
Remember, a template is only instantiated once for each set of
arguments and
the same instantiation can be repeated in multiple modules
throughout a
program. If each instantiation were scoped locally, the
template would no
longer work as expected.
That leads me to speculate that it should be possible to use a
class template as a sort of singleton. But, because a class
template (from what I understand currently) needs to be
instantiated using 'new,' I'm thinking maybe it isn't possible.
Can you (or someone else) clear this up for me, please?
Instantiating a class template is not like instantiating a single
instance of an object. What it does is create an implementation
of the class, not an instance. So given this:
class Foo(T) {
T item;
}
Then this instantiation (which, byt the way, does not need new --
an alias will do the trick):
alias IntFoo = Foo!int;
Essentially does this:
class FooWithInt {
int item;
}
Of course, the symbol will be different than 'FooWithInt', but
the point is for every T there has to be a uniquely named
implementation of Foo.
What I have in mind is a template wrapped around a GTK
AccelGroup that could then be instantiated in the MainWindow as
well as inside any MenuItem needing a keyboard shortcut
assignment.
Off the top of my head, to get a Singleton template, you could
implement all of your singleton plumbing (thread safety if you
need it, etc) in the template and add a `static _instance` member
just as you would for any non-templated singleton:
class Singleton(T) {
private static Singleton!T _instance;
static Singleton!T instance() {
if(_instance is null) {
_instance = new Singleton!T;
}
...
}
private T _thing;
...
}
And you can then instantiate directly or, more conveniently, use
an alias:
alias Accelerators = Singleton!AccelGroup;
Then:
Accelerators.instance.doSomething();
Re: Templates - What's Up with the template keyword?
On Monday, 8 April 2019 at 12:23:28 UTC, Ron Tarrant wrote:
First, the question...
In Michael Parker's book, "Learning D," (Packt, 2015) on page
160 he gives an example of a basic template:
template MyTemplate(T)
{
T val;
void printVal()
{
import std.stdio : writeln;
writeln("The type is ", typeid(T));
writeln("The value is ", val);
}
}
But in "Programming in D," (self, 2009-2018) by Ali Çehreli,
there's no mention of the 'template' keyword in any of his
examples.
Has the 'template' keyword been deprecated? Or is it optional?
You should have read further along in that chapter :-) I evolve
the MyTemplate example through the end of that "Templates as code
blocks" section to this:
template MyTemplate(T) {
struct ValWrapper {
T val;
void printVal() {
import std.stdio : writeln;
writeln("The type is ", typeid(T));
writeln("The value is ", val);
}
}
}
And show that it must be instantiated like this:
void main() {
MyTemplate!int.ValWrapper vw1;
MyTemplate!int.ValWrapper vw2;
vw1.val = 20;
vw2.val = 30;
vw1.printVal();
vw2.printVal();
}
And in the next section, "Struct and class templates", I
introduce the concept of eponymous templates by rewriting
MyTemplate like so:
template ValWrapper(T) {
struct ValWrapper {
T val;
void printVal() {
writeln("The type is ", typeid(T));
writeln("The value is ", val);
}
}
}
And show that it can be instantiated with the shorthand:
ValWrapper!int vw;
And that the template can be refactored to this (since it's
eponymous):
struct ValWrapper(T) {
T val;
void printVal() {
writeln("The type is ", typeid(T));
writeln("The value is ", val);
}
}
In the subsequent sections, I show both long and short
(eponymous) forms of enum and function templates.
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 07:25:40 UTC, Mike Parker wrote: documentation. Instead, it belongs in the DMD windows documentation. It's currently missing: https://dlang.org/dmd-windows.html#linking The 32-bit COFF support is missing there I mean. It does specifically mention that there are different linkers involved in the 32-bit and 64-bit toolchain.
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 07:10:51 UTC, Robert M. Münch wrote: t. My missing point was, that I didn't expect to work with two different links. And I totally agree, DUB needs to mention this. Make everyones live easy. I don't want to dig through fragmented information, collect and sort all pieces etc. That's just waste of time. If I use DUB, I want to see all things around building D programs. That simple... Is there an I have never seen *-x86_mscoff mentioned anywhere... Again, this has nothing to do with dub. It's the behavior of the linkers. When you use WinMain, the MS Linker will give you a windows subsystem by default. When you use main, it will give you a console subsystem. DMD gained the -m32mscoff a good while ago in order to enable coff output and compatibility with the MS linker in 32-bit mode. Built-in dub support came much later with x86_mscoff. *That* needs to be documented in the dub docs, but the behavior of the various linkers out there is beyond the scope of dub's documentation. Instead, it belongs in the DMD windows documentation. It's currently missing: https://dlang.org/dmd-windows.html#linking
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 04:32:57 UTC, evilrat wrote: On Tuesday, 5 March 2019 at 03:48:22 UTC, Mike Parker wrote: I stopped using WinMain with D a long time ago. It's not necessary. If you always use `main`, then both linkers will provide you with a console subsystem app by default. That's particularly useful during development. You can add a configuration to your dub.json that turns on the windows subsystem for both linkers. For OPTLINK (x86) you only need to pass to the linker `/SUBSYSTEM:windows`. For the MS linker (x86_mscoff, x86_64) you need to that and you need to specify that the entry point is `main`, because it will expect `WinMain` when you specify the windows subsystem. You can do that with `/ENTRY:mainCRTStartup` https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2017 https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=vs-2017 All of this should be added on dub docs with small snippets and explanation as a section dedicated to Windows and maybe even on D docs as well, because you know, it shows up again and again from time to time This has nothing to do with dub, so that’s the wrong place for it. The dmd for windows docs needs to make clear the distinction between the linkers and the differences in behavior, and point to the linked docs for options. I just checked the Optlink page and didn’t see /subsystem documented, so that needs to be fixed. I’ll put it on my todo list.
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Monday, 4 March 2019 at 18:34:09 UTC, Robert M. Münch wrote:
Hi, when compiling a minimal Windows GUI app (using WinMain())
and compiling it with DUB, the 32-bit x86 version is a
character subsystem EXE (writeln works) and for x86_64 it's a
GUI subsystem EXE (writeln doesn't work). Since compiling the
same source, with the same DUB config file, I would expect the
x86 and x86_64 version to be equal.
That's the DUB JSON I use:
{
"targetType" : "executable",
"libs-windows-x86_64": ["user32", "gdi32"],
"libs-windows-x86" : ["gdi32"],
}
So, how can I get a character subsystem for x86_64 and a GUI
subsystem for x86?
I stopped using WinMain with D a long time ago. It's not
necessary. If you always use `main`, then both linkers will
provide you with a console subsystem app by default. That's
particularly useful during development. You can add a
configuration to your dub.json that turns on the windows
subsystem for both linkers.
For OPTLINK (x86) you only need to pass to the linker
`/SUBSYSTEM:windows`.
For the MS linker (x86_mscoff, x86_64) you need to that and you
need to specify that the entry point is `main`, because it will
expect `WinMain` when you specify the windows subsystem. You can
do that with `/ENTRY:mainCRTStartup`
https://docs.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=vs-2017
https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=vs-2017
Re: DUB / compiling same source and config to different windows subsystems in 32/64 bit
On Tuesday, 5 March 2019 at 02:13:30 UTC, evilrat wrote:
This should do for MS linker
"lflags-windows-x86_64": ["/SUBSYSTEM:CONSOLE"],
"lflags-windows-x86_mscoff": ["/SUBSYSTEM:WINDOWS"]
For old optlink x86 it is a bit harder, you need to include
special .def file that has instruction for linker, here is an
example from dlangui[2], adding it with linker libs should
work, probably, or maybe, or...
No, you don't need a def file. OPTLINK understands the same
option:
hello.d
```
void main() {
import std.stdio;
writeln("Hello");
```
`dmd hello` outputs "hello"
`dmd -L/SUBSYSTEM:windows hello` outputs nothing.
Re: Why is SwitchError an error and how is it unsafe to continue after catching it?
On Sunday, 24 February 2019 at 10:53:09 UTC, aliak wrote:
Because from what I understand, an Error is something you
should not be catching and represents something unrecoverable.
And it the docs say that it's unsafe to continue execution. But
the following code is very recoverable and I don't see how it's
unsafe to continue executing:
import optional;
import core.exception: SwitchError;
enum Enum : string {
one = "one", two = "two"
}
Optional!Enum makeEnum(string value) {
try {
final switch (value) {
case Enum.one: return some(Enum.one);
case Enum.two: return some(Enum.two);
}
} catch (SwitchError) {
return no!Enum;
}
}
unittest {
assert(makeEnum("one") == some(Enum.one));
assert(makeEnum("huh") == no!Enum);
}
Cheers,
- Ali
These days you can disable the check on final switches:
-check=switch=off
However, in this case, I would say you should actually be using a
normal switch because your input is not an enum and you aren't
constraining its value. IMO, using any type other than an enum as
the input for a final switch should be a compiler error.
Re: Next steps of approved DIPs
On Wednesday, 20 February 2019 at 11:52:35 UTC, Peter Particle wrote: In particular I am interested in DIP 1014 but this question can be applied to any approved DIP. Where do I get information about e.g. implementer, implementation state/progress, which DMD version is expected to include it (apparently not 2.0.85), etc.? Normally the DIP author should be on top of that. Any time that's not the case, you can contact me directly and I'll see what's up. I'll see what's up with 1014 and reply here if someone involved doesn't get to it first.
Re: Is there a way to replace Exception with as a macro in C?
On Tuesday, 19 February 2019 at 06:16:59 UTC, Mike Parker wrote:
```
Exception invalidIndexException() { throw new Exception("Index
is invalid"); }
Eh, that should be:
void invalidIndexException() {...}
Re: Is there a way to replace Exception with as a macro in C?
On Tuesday, 19 February 2019 at 05:50:04 UTC, yisooan wrote:
This is allowed.
But I want to do the exact same thing in D. I have already
tried some expressions with alias? but it doesn't work.
alias can't be used for expressions.
Would you help me, please?
There's nothing exactly equivalent to the C preprocessor. The
closest you'd be able to get without using a keyword like mixin
is to use a function:
```
Exception invalidIndexException() { throw new Exception("Index is
invalid"); }
if(false) invalidIndexException;
```
Of course, you can also subclass Exception:
```
class InvalidIndexException : Exception
{
this(string file = __FILE__, size_t line = __LINE__)
{
super("Index is invalid", file, line);
}
}
if(false) throw new InvalidIndexException;
```
Re: Linux & DMD & GtkD
On Saturday, 16 February 2019 at 13:35:57 UTC, Ron Tarrant wrote: dmd -de -w -m64 -L+gtkd hello_gtkd_world.d DMD's -L switch means "pass the following flag to the linker". Linker arguments are system-dependent. The + is what you use on Windows to specify the library path when running DMD with the default 32-bit linker (optlink). On Linux, it's actually -L, so you should be specifying -L-Lgtkd. Assuming, of course, gtkd is the path and not the library name.
Re: How to disable/hide constructor when using factory method?
On Thursday, 24 January 2019 at 12:58:15 UTC, JN wrote:
Doh. Of course. I feel so dumb. I just had it at @disable
this();, then replaced @disable with private without thinking
to add {}
Give me a nickel for every time I've made an edit like that...!
Re: Interfacing with C libs: weeding through C/C++ macros and such in header files
On Sunday, 13 January 2019 at 22:40:57 UTC, Alec Stewart wrote:
Example without code; for some reason a macro is defined for
the stdlib functions `malloc`, `realloc`, and `free`. Maybe
it's just because I don't have any pro experience with C or
C++, but that seems a bit excessive. Or I could just be dumb.
Generally this is done to allow the compile-time configuration of
memory allcoators. Back in my C days I had a little memory module
that tracked total allocated and unallocated bytes and logged a
few stats to a file at shutdown. I used macros to switch between
it and the default stdlib calls.
I understand what it's doing, but do I really any of this with
D?
No.
And then there's this inline function
#define RS_DATA_SIZE(f, s, input)
\
do {
\
if (rs_is_heap(input)) \
f(s, input->heap.buffer, rs_heap_len(input)); \
else\
f(s, input->stack.buffer, rs_stack_len(input)); \
} while (0)
Generally, this sort of thing can be moved into a D function or
template if it's repeated in several places. Without the
do...while, of course. And in case you're unfamiliar with its
purpose here:
https://stackoverflow.com/questions/154136/why-use-apparently-meaningless-do-while-and-if-else-statements-in-macros
Re: Libraries, versions, API changes, and Dub
On Thursday, 10 January 2019 at 10:28:55 UTC, Mike Parker wrote: to set up compile-time versions Compile-time *values* else enum dvbvSupport = DVBVSupport.v114; This, of course, should be = DVBVSupport.v112
Re: Libraries, versions, API changes, and Dub
On Thursday, 10 January 2019 at 05:44:22 UTC, Russel Winder wrote:
It appears that libdvbv5 has undergone an (unnoticed by me till
just now) version change. This raises a general question for
creators of D bindings.
libdvbv5 has versions 1.12.x, 1.14.x, 1.16.x, etc, following
the "odd is internal, even is released" minor version number
strategy. It seems wrong somehow to follow that numbering for
the D binding; the binding needs to have a separate evolution.
However the binding has to allow the user to choose the
major.minor number of the underlying library they have – though
that should perhaps be done automatically using the pkg-config
system.
Has anyone had previous experience of this situation and can
give advice/direction so I don't have to build a solution from
first principles?
Use version conditions for the different library versions to set
up compile-time versions you can static if on:
```
enum DVBVSupport {
v112 = 112,
v114 = 114,
v116 = 116,
}
version(DVBV_114) {
enum dvbvSupport = DVBVSupport.v114;
}
else version(DVBV_116) {
enum dvbvSupport = DVBVSupport.v116;
}
else enum dvbvSupport = DVBVSupport.v114;
// Declarations supported in 1.12
...
static if(dvbvSupport >= DVBVSupport.v114) {
...
}
static if(dvbvSupport >= DVBVSupport.v116) {
...
}
```
This is how I handle it in the BindBC libraries, to which I'm
porting all the active bindings from the DerelictOrg group (where
I handled it with different git branches, which is a horribly
confusing and inefficient way to go about it):
https://github.com/BindBC
The only drawback to it right now is that static if isn't
supported inside enum declarations, so you'll wind up with
multiple declarations of the enum, as I did with SDL_EventType
here:
https://github.com/BindBC/bindbc-sdl/blob/master/source/bindbc/sdl/bind/sdlevents.d#L25
static if *is* supported in class & struct delcarations, though,
and you can see it used in that same file in some of the event
types, like SDL_MouseButtonEvent and SDL_MouseWheelEvent:
https://github.com/BindBC/bindbc-sdl/blob/master/source/bindbc/sdl/bind/sdlevents.d#L347
Re: Co-developing application and library
On Saturday, 5 January 2019 at 15:17:28 UTC, Mike Parker wrote: On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote: Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub. What I do is use `dub add-local /path/to/lib 0.0.1` and use that explicit version for development. That way, whatever repository branch is currently active in that directory becomes version 0.0.1 and I can make use of any changes. Alternatively, I sometimes use the path to the library rather than a version specification in the package recipe. With the SDLang format: dependency mylib path="path/to/lib"
Re: Co-developing application and library
On Saturday, 5 January 2019 at 13:01:24 UTC, Russel Winder wrote: Dub seems to have the inbuilt assumption that libraries are dependencies that do not change except via a formal release when you developing an application. Clearly there is the workflow where you want to amend the library but not release as a part of developing an application. Does Dub have a way of doing this, I haven't been able to infer one to date. But I am a beginner at Dub. What I do is use `dub add-local /path/to/lib 0.0.1` and use that explicit version for development. That way, whatever repository branch is currently active in that directory becomes version 0.0.1 and I can make use of any changes.
Re: Compile time opAssign/@property constraints
On Friday, 4 January 2019 at 11:53:41 UTC, Jacob Shtokolov wrote:
On Friday, 4 January 2019 at 11:45:24 UTC, Jacob Shtokolov
wrote:
Here is the simple example:
https://run.dlang.io/gist/1a06dd703bea5548ee72b4713a7ce5f6
Sorry, invalid link.
Here is a new one: https://run.dlang.io/is/QZ5hLV
```
@property val(T v) {
static assert(v > 0);
value = v;
}
```
v is a run-time value, not available at compile time.
Re: D-oriented Syntax Highlighting Plugin for WordPress?
On Tuesday, 1 January 2019 at 20:27:44 UTC, Ron Tarrant wrote: On Tuesday, 1 January 2019 at 18:10:49 UTC, Mike Parker wrote: We're using Mivhak Syntax Highlighter on the D Blog. OOTB, or...? I couldn't find a list of supported languages. It supports D out of the box.
Re: D-oriented Syntax Highlighting Plugin for WordPress?
On Tuesday, 1 January 2019 at 14:46:15 UTC, Ron Tarrant wrote: I've found a ton of syntax highlighter plugins for WordPress, but none that admit to supporting D. Anyone know of one? Or, short of that, perhaps a different site build/management tool (read: not WordPress) with decent D syntax highlighting... Or, one that can be adapted without rolling my sleeves much past my wrists. We're using Mivhak Syntax Highlighter on the D Blog.
Re: Doubt about this book: The D Programming Language
On Sunday, 16 December 2018 at 22:02:44 UTC, bachmeier wrote: Sometimes Packt has sales and you can get them pretty cheap. All Packt ebooks are on sale for $5 right now, so this is a great time to pick up both books along with Kai's Vibe.d book.
Re: Doubt about this book: The D Programming Language
On Monday, 17 December 2018 at 06:08:58 UTC, Jani Hur wrote: Publish dates are 2014 and 2015. How much the language has changed/evolved since then and how much it will evolve in future ? So are these books relevant today and still next two years ? There haven't been any changes in the language significant enough to make either book irrelevant, nor will there be for a while. And the authors of both books hang out on the forums if you find any inaccuracies you'd like to ask about.
Re: How may I tell dub where to find a C library for linking?
On Monday, 10 December 2018 at 15:38:24 UTC, Pab De Nápoli wrote: 1) Setting the LD_LIBRARY_PATH environment variable with export LD_LIBRARY_PATH=/usr/lib/llvm-6.0/lib/ and using "libs" : ["LLVM-6.0"] in dub.json. (this is somewhat nasty, it would be nice to keep all the information together in dub.json) Moreover, the information about the path for linking with LLVM can be obtained from the shell script llvconfig as $llvm-config-6.0 --libs --ldflags -L/usr/lib/llvm-6.0/lib -lLLVM-6.0 If you do want to put it in the dub config, the -L option, and any linker options, can go in the "lflags" directive. "libs" is for libraries only. "lflags": ["-L/usr/lib/llvm-6.0/lib"], "libs": ["LLVM-6.0"]
Re: dip1000 rule 5
On Tuesday, 27 November 2018 at 08:56:47 UTC, sclytrack wrote: --- How is a person able to understand this DIP? ./dmd -betterC -dip1000 test.d I'll repeat: the DIP does not currently match the implementation. I was not involved in any of it and have no idea what the diff actually is. Walter informed me a while back that he will update the DIP to match the implementation at some point. I'll discuss it with him after the new year and see where we are. --- How many DIP manager are there? I'll assume single person. Yep, just me. When is a DIP assigned a number? --- As soon as I merge the PR. That's the point where it moves from Draft Review to the first round of Community Review (and I will update the procedures doc to reflect that). Which DIPs get merged when depends on a number of factors -- what is the state of each DIP, what's the priority, how many are currently under review in the post-Draft stages, is the author available to move forward, etc.
Re: dip1000 rule 5
On Sunday, 25 November 2018 at 21:22:09 UTC, sclytrack wrote: Did DIP1000 go through any review process? I'm seeing it is a draft. The previous DIP manager marked DIPs as Draft while they were under review. I don't use that anymore. I left DIP1000 untouched after I took over, however. Walter told me he'll revise it at some point to reflect the actual implementation. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md Keeps talking about a Drafts subdirectory. I don't see any directory named "Drafts". It was originally my intention to push new DIPs into a Drafts subdirectory for the Draft Review stage, but it's more convenient to handle it in the pull request thread. I never edited the document to reflect that and didn't notice it when I've looked it over. Now that you've pointed it out, I'll revise it.
Re: D is supposed to compile fast.
On Sunday, 25 November 2018 at 22:00:21 UTC, Chris Katko wrote: So 1) I have to compile manually, then link. Except that also runs the files every time even if they're up-to-date. Is that normal behavior for C/C++? Yes, C and C++ compilers behave the same way. #1 How to I only build files that are dirty? Do I actually need a build program like DUB, MAKE, or CMAKE to do that? (Can make, cmake be used?) How do they recognize files are out-dated if DMD can't? Is that just an industry-standard specialization/separation-of-responsibilities to not have the compiler auto-detect up-to-date builds? cmake doesn't actually build anything. It generates make files or IDE project files. I don't know if DUB currently has an option to build only dirty files. Make does it by default. To do something like that requires looking for a source file's corresponding object file in the output directory and only compiling the source if the object file doesn't exist or if it has an older timestamp. But consider what happens when you change the command line options, say enable a version on a build that wasn't enabled earlier. With make, you have to run `make clean` first, otherwise only dirty files will get the new options. It doesn't track build options per file from run to run. What should the compiler do? Have a -clean command line switch? Maintain a database of command line options per file? That's the realm of build systems. The compiler just compiles. I've heard "just use dub" but I've also heard that dub have flaws/gotchas that I can't remember when it comes to say, dynamic linking DLLs/SOs. So I've been hesitant to learn it. DUB is easy. I've been using it for years and I do full compilation of every file on every invocation in a code->build->run cycle. Some aren't happy with it because it doesn't support some of the things they want to use it for, but it has plenty of satisfied users. I'm unaware of any gotchas about linking shared libraries. #2 I ran individual file times. They're pretty shocking. --- I have to tell you that, as an outsider (who is VERY interested in D), this is very frustrating. "Compile times are fast" != "build times" is a huge misconception that borders on being a clever lie or twisting of words. When people hear "compile times", they think "time to compile the whole project" not "time to compile a simple test case that doesn't use any typical D features--also, it's not linking." Second, as shown here, it's not fast even for compiling! Because the second you touch std.regex (which has NO WARNINGS in the documentation), you're greeted with another clever lie-by-omission: a 10x explosion of build time over some modules. Now let's stop for a moment. I'm not accusing anyone, and "lie" is a strong word with heavy guilt implications--like people are intentionally being very sneaky to deceive new-comers. I'm not saying any of that, so you can relax and put down the pitchfork. I'm not attacking you or your group personally. However, I can't think of any better word. So my point is, I keep running into either misconceptions that conveniently make D look good, and other gotchas with NO DOCUMENTATION that make the language much slower to work with than expected. There is no misleading or misconception or lying or misdirection here. DMD has fast compile times. Heavily templated code is going to slow it down, but if you compile the same sort of heavily templated code in C++, you'll get slow downs there as well. And in your case, you'll find that if you add many more files to your project and they aren't heavily templated, the increase in build time will be very small. If someone can dig into the compilers and optimize how templates are handled, they might be able to shave a bit of time off, but when you are using a code base that does a lot of work at compile time, then there's no avoiding increasing the length of that compile time. But that by no means is the same as saying it's not fast, because overall compile times in D are still fast. I mean, can you think of any module in the Python/Javascript/C# standard library that simply including it will swell your program to the point it can't compile? I'm not an omnipotent master programmer, but as a professional, I can't recall ever having this situation in another library or language. Have you reached the point in D where you can't compile?
