Re: Local library with dub
On Wednesday, 21 April 2021 at 19:15:19 UTC, Jordan Wilson wrote: On Wednesday, 21 April 2021 at 15:07:25 UTC, JG wrote: On Wednesday, 21 April 2021 at 00:39:41 UTC, Mike Parker wrote: [...] Thanks. I suppose this means that if you want to able to use multiple versions you have to keep each version in a separate directory and add them individually, and there is no way of being able to get the appropriate version from say a git repository? You can specify git repos as dependencies, if this helps. https://dlang.org/changelog/2.094.0.html#git-paths Jordan Thanks, I will see if I can use this.
Re: dlang opengl / gl / glu /glut library.
My lapsus. I've got dgame & raylib-d working. I wander how I start with sdl/opengl.
Re: Dlang equivalent of #define/#ifdef : not... version
On Tuesday, 20 April 2021 at 18:57:46 UTC, ichneumwn wrote:
Hi,
Trying to convert a C header to D. The underlying package
exists in different versions and may or may not expose certain
functionality (modules/extensions). One should check at compile
time that the header provides the relevant definitions, through
#ifdef, and do a further run-time check to confirm the
functionality is really present. It is the compile time check
that I am finding tricky to do/emulate.
.h : #define i_am_a_feature 1
The C-code uses this define as a guard:
.c : #ifdef i_am_a_feature
What would the the D equivalent? This is my attempt so far:
features.d:
import std.traits;
private enum capabilities {
i_am_a_feature
}
template supported(string member)
{
enum bool supported = hasMember!(capabilities, member);
}
version = vs_i_am_a_feature;
enum can_i_test_for_this;
and use.d:
import features;
import std.stdio;
void main() {
static if (supported!("i_am_a_feature")) {
writeln("Feature 1!");
}
static if (supported!("i_am_not_a_feature")) {
writeln("Feature 2!");
}
version(vs_i_am_a_feature) {
writeln("If only I worked");
}
}
This produces "Feature 1!", so the supported() path works, but
is a bit of a round-about way and all "capability flags" need
to put in that single enum capabilities instead of being
allowed to be scattered across the features.d module.
As is documented, "version" does not cross the module boundary.
So my questions:
- is there a module-crossing equivalent of "version"?
- if not, is there some way I could test for the existence of
the enum can_i_test_for_this? A SymbolExists!() or
ModuleHasSymbol!() or ModuleHasMember!() ?
Cheers
Between them, Simen and Ali have cracked the case. Ali's
demonstration that "true" was returned made me look at it further
and tried the module's name directly and that worked too. It
seems that Simen's expansion of hasMember() into the __traits
version does the trick -- the __traits version *does* accept the
module as a parameter. It seems the template expansion does not
like module arguments, not __traits itself. Here is the demo:
features.d:
import std.traits;
enum can_sing = 1;
enum can_dance = 1;
template supported(string member) {
enum bool supported = __traits(hasMember, features,
member);
// features can be replaced by: mixin(__MODULE__)
// to make this module robust against renaming
}
/*
* Note that using std.traits.hasMember *does not* work.
Yields error:
* template instance hasMember!(features, "can_sing") does
not match template
* declaration hasMember(T, string name)
*/
use.d:
import features;
import std.stdio;
import std.traits;
void main() {
static if (supported!"can_sing") {
writeln("can_sing");
}
static if (supported!("can_dance")) {
writeln("can_dance");
}
static if (supported!("can_jump")) {
writeln("can_jump");
}
}
Result:
can_sing
can_dance
I think the version with the mixin is neater, but I have put it
in the direct "features" in the example to show it is not
actually necessary.
Oh, I found a bonus option: passing the module as an argument. I
do not really get templates beyond the very basic ones, but I
remember seeing "alias" somewhere and that gets the module
through my own template:
// accept module as argument
template supported(alias modname, string member) {
enum bool supported = __traits(hasMember, modname,
member);
}
// accept module name (string) as argument:
template supported(string modname, string member) {
enum bool supported = __traits(hasMember, mixin(modname),
member);
}
As I write this, I realise that the alias can also be used to get
a version of hasMember that accepts modules:
enum hasMember(alias T, string name) = __traits(hasMember, T,
name);
Although that might have unintended side effects? And, indeed,
shorten my own use case to:
enum supported(string member) = __traits(hasMember,
mixin(__MODULE__), member);
Many thanks to everyone with suggestions!
Re: dlang opengl / gl / glu /glut library.
On 22/04/2021 7:51 AM, Alain De Vos wrote: import bindc.opengl; bindbc
Re: dlang opengl / gl / glu /glut library.
First opengl test.
Link library.
```
import std.stdio;
import bindc.opengl;
void main()
{
writeln("Edit source/app.d to start your project.");
}
x: /home/x/Src/languages/dlang/opengl >
```
dub.json:
```
"authors": [
"x"
],
"copyright": "Copyright © 2021, x",
"dependencies": {
"bindbc-opengl": "~>0.16.0",
},
"description": "A minimal D application.",
"license": "proprietary",
"name": "opengl"
}
```
dub build
```
dub build
Performing "debug" build using /usr/local/bin/ldc2 for x86_64.
bindbc-loader 0.3.2: target for configuration "noBC" is up to
date.
bindbc-opengl 0.16.0: target for configuration "dynamic" is up to
date.
opengl ~master: building configuration "application"...
source/app.d(2,8): Error: module opengl is in file
'bindc/opengl.d' which cannot be read
import path[0] = source/
import path[1] =
/home/x/.dub/packages/bindbc-opengl-0.16.0/bindbc-opengl/source/
import path[2] =
/home/x/.dub/packages/bindbc-loader-0.3.2/bindbc-loader/source/
import path[3] = /usr/local/include/d
/usr/local/bin/ldc2 failed with exit code 1.
```
Re: Local library with dub
On Wednesday, 21 April 2021 at 15:07:25 UTC, JG wrote: On Wednesday, 21 April 2021 at 00:39:41 UTC, Mike Parker wrote: On Tuesday, 20 April 2021 at 18:43:28 UTC, JG wrote: This still leaves open the question of how to include a version of such a library in another project via dub. Execute `dub add-local` followed by the path to the project's root directory (the directory containing the `dub.json/sdl`) and a version number in semver format. ``` dub add-local path 0.1.0 ``` Then you can use the package just as you would any other dub dependency. Thanks. I suppose this means that if you want to able to use multiple versions you have to keep each version in a separate directory and add them individually, and there is no way of being able to get the appropriate version from say a git repository? You can specify git repos as dependencies, if this helps. https://dlang.org/changelog/2.094.0.html#git-paths Jordan
Re: Voldemort type "this" pointer
On 4/21/21 8:37 AM, realhet wrote:
On Wednesday, 21 April 2021 at 10:47:08 UTC, Mike Parker wrote:
On Wednesday, 21 April 2021 at 10:00:51 UTC, realhet wrote:
It has access to the context of its enclosing scope (via an added
hidden field).
Thanks!
So it is unsafe to return a non-static nested struct from a function.
But it is useful to pass it forward into other functions.
Not at all. (D is good at preventing such bugs anyway.)
The local context that the nested struct object uses becomes the context
of that object. Here is a poor person's proof (one can inspect the
assembly output to observe delegate allocation as well):
import std.stdio;
auto foo() {
int i;
writeln(&i, " <- dynamic memory inside foo");
struct S {
void bar() {
writeln(&i, " <- dynamic memory inside bar");
}
}
return S();
}
void main() {
int m;
writeln(&m, " <- stack address inside main");
auto s = foo();
s.bar();
}
Sample output strongly suggests 'i' is not on the stack because the
addresses are distant:
7FFFC14D85C0 <- stack address inside main
7FF424B9C008 <- dynamic memory inside foo
7FF424B9C008 <- dynamic memory inside bar
Ali
Re: Voldemort type "this" pointer
On Wednesday, 21 April 2021 at 10:47:08 UTC, Mike Parker wrote: On Wednesday, 21 April 2021 at 10:00:51 UTC, realhet wrote: It has access to the context of its enclosing scope (via an added hidden field). Thanks! So it is unsafe to return a non-static nested struct from a function. But it is useful to pass it forward into other functions.
Re: Local library with dub
On Wednesday, 21 April 2021 at 00:39:41 UTC, Mike Parker wrote: On Tuesday, 20 April 2021 at 18:43:28 UTC, JG wrote: This still leaves open the question of how to include a version of such a library in another project via dub. Execute `dub add-local` followed by the path to the project's root directory (the directory containing the `dub.json/sdl`) and a version number in semver format. ``` dub add-local path 0.1.0 ``` Then you can use the package just as you would any other dub dependency. Thanks. I suppose this means that if you want to able to use multiple versions you have to keep each version in a separate directory and add them individually, and there is no way of being able to get the appropriate version from say a git repository?
Re: dlang opengl / gl / glu /glut library.
On Sunday, 18 April 2021 at 22:35:26 UTC, Alain De Vos wrote: Is there a library with api index ? https://github.com/BindBC/bindbc-opengl use the version block you need: https://github.com/BindBC/bindbc-opengl#enable-support-for-opengl-versions-30-and-higher
Re: Dlang equivalent of #define/#ifdef : not... version
On 4/21/21 2:38 AM, Dukc wrote:
On Tuesday, 20 April 2021 at 23:58:46 UTC, Steven Schveighoffer wrote:
static if(i_am_a_feature) {
...
}
This would be correct if `i_am_a_feature` would be always defined, just
set to `false` if not existent. But I think the idea was to not define
the symbol at all if feature does not exists. In that case, the
condition should be `static if(is(typeof(i_am_a_feature)))`.
Yeah, you're right. It's different than ifdef.
I think version is the closest thing.
Note that you can convert versions into enums via:
version(define_the_thing)
{
enum the_thing_is_defined = 1;
}
else
{
enum the_thing_is_defined = 0;
}
-Steve
Re: Iteratable single linked list of floats.
21.04.2021 16:19, Alain De Vos пишет:
import std.stdio;
void main(){
struct List {
struct Node {
float f;
Node *next;
}
Node * root=null;
bool empty() const {return !root;}
void popFront() {root=root.next;}
float front() const {return root.f;}
void push(float f) {
Node * newnode=new Node();
newnode.f=f;
root.next=newnode; // Segmentation fault
}
}
List * l=new List();
l.push(3);
foreach(element;l){ // Invalid foreach aggregate
writeln(element.root.f);
}
}
```D
import std.stdio;
void main(){
struct List {
struct Node {
float f;
Node *next;
}
Node * root=null;
bool empty() const {return !root;}
void popFront() {root=root.next;}
float front() const {return root.f;}
void push(float f) {
Node * newnode=new Node();
newnode.f=f;
if (root) // by default root is null so you need to
initialize it first time
root.next=newnode;
else
root = newnode;
}
}
List * l=new List();
l.push(3);
foreach(element; *l){ // Invalid foreach aggregate because `l` is a
pointer to List, so you need to dereference the pointer
writeln(element);
}
}
```
1) you need to initialize the root
2) pointer to range is not valid foreach aggregate
Re: Iteratable single linked list of floats.
Formatted ,
```
import std.stdio;
void main(){
struct List {
struct Node {
float f;
Node *next;
}
Node * root=null;
bool empty() const {return !root;}
void popFront() {root=root.next;}
float front() const {return root.f;}
void push(float f) {
Node * newnode=new Node();
newnode.f=f;
root.next=newnode; // Segmentation fault
}
}
List * l=new List();
l.push(3);
foreach(element;l){ // Invalid foreach aggregate
writeln(element.root.f);
}
}
```
Iteratable single linked list of floats.
I try to create manually and explicit an interetable single
linked list of floats. Probably one of the most basic
datastructures.
import std.stdio;
void main(){
struct List {
struct Node {
float f;
Node *next;
}
Node * root=null;
bool empty() const {return !root;}
void popFront() {root=root.next;}
float front() const {return root.f;}
void push(float f) {
Node * newnode=new Node();
newnode.f=f;
root.next=newnode; // Segmentation fault
}
}
List * l=new List();
l.push(3);
foreach(element;l){ // Invalid foreach aggregate
writeln(element.root.f);
}
}
But I have a segmentation fault and an invalid foreach aggregate
Re: Voldemort type "this" pointer
On Wednesday, 21 April 2021 at 10:00:51 UTC, realhet wrote: My question is about what is the "this" pointer for. Is it for storing the stack frame of the function in order to be able to serve queries that can lazily use the data from the stack frame? (I guess it's something else because that part of the stack might be undefined after exiting from the function.) From the documentation 1. A nested struct is a struct that is declared inside the scope of a function or a templated struct that has aliases to local functions as a template argument. Nested structs have member functions. It has access to the context of its enclosing scope (via an added hidden field). 2. A struct can be prevented from being nested by using the static attribute, but then of course it will not be able to access variables from its enclosing scope. https://dlang.org/spec/struct.html#nested
Voldemort type "this" pointer
Hi, I noticed that there is a hidden "this" pointer in a struct that I declare inside a body of a function. Also noticed when I use the "static" keyword, the "this" pointer disappears. My question is about what is the "this" pointer for. Is it for storing the stack frame of the function in order to be able to serve queries that can lazily use the data from the stack frame? (I guess it's something else because that part of the stack might be undefined after exiting from the function.)
Re: dlang opengl / gl / glu /glut library.
On Sunday, 18 April 2021 at 23:36:58 UTC, Alain De Vos wrote: When doing graphics the number of functions explodes. So one needs always a list, compare to a header file in c. If there are "modern" alternatives to opengl feel free. More modern from which perspective? Simpler to use (non-inclusive list of options: SDL2/Allegro/SFML bindings, cairod, DLib, dgame)? Or more modern from GPU acceleration perspective (you're probably wanting derelict-vulkan or derelict-bgfx)?
