Re: Setting the GtkD Include Path in dexed?
On Tuesday, 12 March 2019 at 15:48:14 UTC, Ron Tarrant wrote: I managed to get dexed to compile a single-file dub project, but for completeness sake, I'm also trying to configure it to use dmd (non-dub) to compile GtkD projects using Compilation (menu) > Compile File and Run. To that end, I have two questions... Should I be supplying dexed with the include (read: import) path: /usr/include/dmd/gtkd3/ Or the runtime: /usr/lib/x86_64-linux-gnu/libgtkd-3.so And where in dexed does one set the path so it can find a library such as gtkd? There's two different things here. 1. "Compile File and Run" It's for the scripts-like program, i.e single module. For this, the dependencies must be registered in the "library manager". An entry defines the import path (the dmd -I option), and the static library file (*.a, *.lib depending on the platform), and a few others fields. When you execute the action "Compile File and Run", the source is analyzed and the rights imports are automatically passed to DMD, if the matching lib is registered in the libman. 2. Dexed projects. The "native" project format was created before I understood that DUB was the official way to make a D project so it's somewhat not recommended to use it, although it works (for example at some points I had translated non trivial projects, such as dlangUI, to this format, and I still have a few stuff working using them). In this case as you've been said you have the dmdOtherOpts, which can be used to pass whatever you want and will be passed to DMD as is, after (however) the IDE variables expansion. see https://basile-z.github.io/dexed/widgets_dexed_project_editor#other-options for more details. But the dexed project format can also use the library manager. In this case, just like for the "runnable modules" the libraries must be registered in the library manager. Then you specify the alias of the dependencies in the project, see https://basile-z.github.io/dexed/widgets_dexed_project_editor#general-options (libraryAliases). example: https://github.com/Basile-z/kheops/blob/master/kheops.dprj#L58 ___ Finally: the most important thing is to register the library in the libman. https://basile-z.github.io/dexed/widgets_library_manager#library-manager
Re: Setting the GtkD Include Path in dexed?
On Tuesday, 12 March 2019 at 21:54:36 UTC, JN wrote: How about Project -> Project editor -> Categories -> Other -> dmdOtherOptions ? I take it this starts in the Project menu? I found Project Editor in the Project menu, but the rest eludes me. Can't find it.
Re: Strange appender behavior
On Wednesday, 13 March 2019 at 13:03:27 UTC, tchaloupka wrote:
Is this expected?:
You never called the constructor, which means it was lazy
initialized... but that was done inside one of the functions,
which received the Appender by value.
So when it set its internal pointer, it was inside a function and
never got seen outside. Similar to if you do
char* a;
void foo(char* a) {
a = new char[](10);
}
foo(a);
If you were to put something before the other calls, it would
work. Or call the constructor (which the little-a appender
function does).
I'm kinda of the opinion this should be a compile error; that it
should force you to call the constructor, so that could be a
minor bug, but it isn't unexpected per se since regular pointers
and arrays work the same way.
Re: Strange appender behavior
On Wednesday, 13 March 2019 at 13:03:27 UTC, tchaloupka wrote:
Is this expected?:
```
import std.stdio;
import std.algorithm;
import std.array;
void main()
{
auto d = Appender!string();
//auto d = appender!string(); // works
string[] arr = ["foo", "bar", "baz"];
arr.joiner("\n").copy(d);
writeln(d.data);
}
```
Using Appender outpust nothing, using appender works ok.
It sounds like a bug. If you use Appender!string(null) it works
fine. Probably a problem with _data init?
Strange appender behavior
Is this expected?:
```
import std.stdio;
import std.algorithm;
import std.array;
void main()
{
auto d = Appender!string();
//auto d = appender!string(); // works
string[] arr = ["foo", "bar", "baz"];
arr.joiner("\n").copy(d);
writeln(d.data);
}
```
Using Appender outpust nothing, using appender works ok.
Why this template code does not compile?
Why this template code does not compile?
///
module runnable;
import std.meta;
import std.typecons;
template FieldInfo(argT, string argName) {
template FieldInfo(Nullable!argT argDefault =
Nullable!argT()) {
}
}
alias processFields(T, string name) =
AliasSeq!(FieldInfo!(T, name)());
void main(string[] args)
{
alias Fields = processFields!(int, "x");
}
///
/tmp/temp_7F58BE2F0150.d(12,34): Error: template
`runnable.FieldInfo!(int, "x").FieldInfo` cannot deduce function
from argument types `!()()`, candidates are:
/tmp/temp_7F58BE2F0150.d(7,5):`runnable.FieldInfo!(int,
"x").FieldInfo(Nullable!int argDefault = Nullable!argT())`
/tmp/temp_7F58BE2F0150.d(16,20): Error: template instance
`runnable.processFields!(int, "x")` error instantiating
LDC - the LLVM D compiler (1.11.0):
based on DMD v2.081.2 and LLVM 6.0.1
Re: Why this template code does not compile?
On Wednesday, 13 March 2019 at 17:38:02 UTC, Victor Porton wrote:
Why this template code does not compile?
///
module runnable;
import std.meta;
import std.typecons;
template FieldInfo(argT, string argName) {
template FieldInfo(Nullable!argT argDefault =
Nullable!argT()) {
}
}
alias processFields(T, string name) =
AliasSeq!(FieldInfo!(T, name)());
The inner `FieldInfo` template isn't a function, but by adding a
second set of parentheses after `(T, name)`, you're attempting to
call it as one.
If you want to instantiate the inner template with its default
argument, you can use `std.meta.Instantiate`:
alias processFields(T, string name) =
AliasSeq!(Instantiate!(FieldInfo!(T, name)));
Re: Returning reference: why this works?
On Wednesday, 13 March 2019 at 20:57:13 UTC, Denis Feklushkin
wrote:
import std.stdio;
struct S { int x; }
ref S func1(ref S i) // i is reference
{
return i;
}
ref S func2(S i) // i is not reference
{
return func1(i); // Works! Possibility to return reference to
local object i?
Indeed, you're invoking UB here. With compiler flag `-dip25` that
code no longer compiles.
-Johan
Returning reference: why this works?
import std.stdio;
struct S { int x; }
ref S func1(ref S i) // i is reference
{
return i;
}
ref S func2(S i) // i is not reference
{
return func1(i); // Works! Possibility to return reference to
local object i?
//return i; // Error: returning i escapes a reference to
parameter i
}
void main() {
auto ret = func2(S(2));
writeln(ret); // "S(2)"
}
Re: Returning reference: why this works?
On Wednesday, 13 March 2019 at 21:04:01 UTC, Johan Engelen wrote:
On Wednesday, 13 March 2019 at 20:57:13 UTC, Denis Feklushkin
wrote:
import std.stdio;
struct S { int x; }
ref S func1(ref S i) // i is reference
{
return i;
}
ref S func2(S i) // i is not reference
{
return func1(i); // Works! Possibility to return reference
to local object i?
Indeed, you're invoking UB here. With compiler flag `-dip25`
that code no longer compiles.
-Johan
Oh, very unexpected! Thank you very much!
