Re: Goto skipping declarations
On Friday, 3 May 2024 at 20:38:31 UTC, Jonathan M Davis wrote: https://issues.dlang.org/show_bug.cgi?id=24535
Goto skipping declarations
In general, you can't skip a declaration with goto, but it seems
to be allowed if the declaration you're skipping is labelled...
Is that expected or an accepts invalid bug?
https://godbolt.org/z/4qx8Pf6G7
```d
void f1(){ //fails with error about skipping a declaration
int x;
goto Label;
int y;
Label:
int z;
}
void f2(){ //compiles fine
int x;
goto Label;
Dummy:
int y;
Label:
int z;
}
```
Dub option for specifying importC include paths
I'm trying to build a wrapper around a lib written in C by having importC compile the .c files, and then providing a nice D API on top. My dub config file seems to be finding the C files to compile without issue, but it's not passing the include dirs for the preprocessor to find headers. Is there an option I'm missing or is there some way to get DUB to do this for me aside from passing like -cpp flags via dflags? From my dub.json: ``` "cSourcePaths": [ "source/libgit2/src/", "source/libgit2/src/util/" ], "cImportPaths" : [ "source/libgit2/src/util/", "source/libgit2/src/libgit2/" ], "importPaths" : [ "source/libgit2/src/util/", ], "excludedSourceFiles" : [ "source/libgit2/src/cli/*.c" ], ``` And the what dub's actually running when it preprocesses the first .c file: ``` /usr/bin/cc -fno-blocks -dD -Wno-builtin-macro-redefined -E -include /opt/homebrew/Cellar/ldc/1.34.0/include/dlang/ldc/importc.h source/libgit2/src/libgit2/annotated_commit.c -o /var/folders/p3/6fcprxgn0xb77hzb031vm1_mgn/T/itmp-ldc-de8fa3/annotated_commit.i ``` Which has doesn't specify any -I flags
Re: Parser
On Wednesday, 14 June 2023 at 09:28:57 UTC, Cecil Ward wrote: I’m thinking that I might had to end up writing a partial, rather rough parser for parts of the D language. Could I get some suggestions for help that I might find in the way of software components? D has a very powerful regex module, I believe. A couple of pointers for general parsers: The Pegged library: https://github.com/PhilippeSigaud/Pegged/tree/master is pretty popular for building general parsers I have a rough implementation a similar idea here: https://github.com/benjones/autoparsed (definitely less polished and probably buggier than pegged). In mine you annotate your types with their syntax and can then call parse!MyType on a token stream to get a MyType.
Re: iota where step is a function
On Thursday, 25 May 2023 at 00:39:02 UTC, anonymouse wrote: I think I misunderstood what was being asked here. My particular use case is to step using * rather than +, so something like for(i = 1; i < N; i *= 2). `sequence` worked for what I was doing well enough
Re: vibe.d mongo updateOne error
On Friday, 21 April 2023 at 20:46:36 UTC, Ben Jones wrote: I'm trying to update an app from an older version of Vibe.d to a newer version that supports modern Mongo (0.9.7-alpha2) [...] Update: https://github.com/vibe-d/vibe.d/pull/2729
vibe.d mongo updateOne error
I'm trying to update an app from an older version of Vibe.d to a newer version that supports modern Mongo (0.9.7-alpha2) I'm replacing an older call to collection.update() to collection.updateOne() instead. I had to change the options parameter to an updated struct, and it now compiles, but I'm getting a runtime error: ```Passed in a regular document into a place where only updates are expected. Maybe you want to call replaceOne instead? (this update call would otherwise replace the entire matched object with the passed in update object)``` On this command _reviews.updateOne(["name" : reviewee], ["$push" : ["reviews" : ins]], options); The code (https://github.com/vibe-d/vibe.d/blob/a1122a0d5c2e1a19ab6fe318cb47784b76d29336/mongodb/vibe/db/mongo/collection.d#L319) looks like it's checking the query part (the first parameter) to find a dollar sign to tell that it's an update, not a document, but I don't understand why. This looks like the queries I see in the mongo doc as well as the mongo session store in vibe: https://github.com/vibe-d/vibe.d/blob/83208ee8d824e28f3e35042e0425026765e47d12/mongodb/vibe/db/mongo/sessionstore.d#L101 Any idea what's going wrong?
Re: Gneric linkedList range adaptor
On Saturday, 11 February 2023 at 05:02:49 UTC, Steven Schveighoffer wrote: Reported https://issues.dlang.org/show_bug.cgi?id=23687 Assuming this is a compiler bug and it gets fixed, does this seem like something worth trying to add to std.range?
Gneric linkedList range adaptor
I'm trying to write a range adaptor for linked list types. The
range type seems to work OK, but my helper function to deduce the
node type has a compiler error. My hunch is that `nextField`
loses its association with T when I'm trying to pass it as a
template parameter inside the helper method, but I can't use
__traits(child) there to fix it.
Any idea how to fix the helper method?
Is this something that would be useful to add to std.range
somewhere? Or is something like it already in Phobos?
Thanks
```
import std.stdio;
import std.range;
struct LinkedListAdaptor(alias nextField, T){
T current;
@safe:
nothrow:
this(T head){
current = head;
}
bool empty() const {
return current == null;
}
T front() {
return current;
}
void popFront() {
current = __traits(child, current, nextField);
}
}
auto linkedListAdaptor(alias nextField, T)(T head) if(is(T == U*,
U)){
return LinkedListAdaptor!(nextField, T)(head);
//fails with:
//onlineapp.d(27): Error: symbol or expression expected as
first argument of __traits `child` instead of `Node*`
// return LinkedListAdaptor!(__traits(child, T, nextField),
T)(head);
}
struct Node{
int data;
Node* next;
}
void main(){
Node* head = new Node(10, new Node(20, null));
auto rng1 = LinkedListAdaptor!(Node.next, Node*)(head);
auto rng = linkedListAdaptor!(Node.next)(head);
foreach(const x; rng){
writeln(x.data);
}
}
```
This fails with:
Error: need `this` for `linkedListAdaptor` of type `pure nothrow
@nogc @safe LinkedListAdaptor!(next, Node*)(Node* head)`
Re: vibe.d + mongoDB
On Friday, 20 January 2023 at 18:58:16 UTC, seany wrote: Hi I am googling to find some vibe.d and mongoDB tutorial. Are their some available? Thank you There's a couple of examples like this one in main vibe repo in the examples directory: https://github.com/vibe-d/vibe.d/tree/master/examples/mongodb When I used it recently, I ran into some issues where upsert operations I wanted to do had changed their wire format in mongo 5 (I think), so I had to use run mongo 4 I'm not aware of any larger tutorials
Re: library to solve the system of linear equations
On Friday, 14 October 2022 at 17:41:42 UTC, Yura wrote: ... Check out MIR https://github.com/libmir
Re: Poste some interesting vibe.d webpages
On Friday, 9 September 2022 at 13:40:45 UTC, Alain De Vos wrote: I find documentation of vibe.d between worse and bad, while the framework is relative OK. There are a few good links on the internet. I post two of them. Feel free to add other web links in order to increase our knowledge. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d https://aberba.com/2016/form-upload-in-vibe-d/ Here's a Vibe.d version of a dice game that I wrote early on in the pandemic. I would have added session support next if I'd continued to work on it: https://github.com/benjones/farkle
Re: How check if destructor has been called?
On Tuesday, 13 September 2022 at 14:06:42 UTC, Injeckt wrote:
Hi, I'm trying to check if destructor has been called, but when
I'm deleting class object I didn't get any calls from
destructor.
myclass.d
~this() {
this.log("\nDestructor\n");
this._free_trash();
}
main.d
try {
server.server_init(server);
} catch (Exception e) {
server.log(e.msg);
server = null;
}
Classes are allocated on the GC heap, so even though you're
setting the reference to null, it's not being collected at that
point. You can use `destroy` to make sure the destructor is
called (see here: https://dlang.org/spec/class.html#destructors)
Or you could make your instance `scope` and then it basically
follows the same lifetime rules as `struct`s.
Re: how to install the new dmd on Mac M1?
On Thursday, 25 August 2022 at 15:19:56 UTC, Steven Schveighoffer wrote: On 8/25/22 10:44 AM, MichaelBi wrote: On Thursday, 25 August 2022 at 14:37:01 UTC, Steven Schveighoffer wrote: On 8/25/22 10:19 AM, MichaelBi wrote: Is there a reason you want to use DMD specifically? If you use homebrew then `brew install ldc dub` will just works for dub projects, and to explicitly run the compiler just use `ldc2` instead of `dmd`. LDC is actually an ARM executable and outputs ARM executables. I assume it's easy to install ldc without homebrew, but I haven' tried.
Re: OK to do bit-packing with GC pointers?
On Friday, 22 July 2022 at 16:57:21 UTC, Steven Schveighoffer wrote: It's specifically undefined behavior by the spec, but in practice, I think it will work, as long as the block you have isn't marked as not allowing interior pointers. See: https://dlang.org/spec/garbage.html#pointers_and_gc Specifically "Do not take advantage of alignment of pointers to store bit flags in the low order bits" -Steve Can you elaborate on why it's probably OK in practice? I guess the alternative to is to to make them structs instead of classes and manually alloc/free them (or keep them as classes, but still avoid the GC)? Seems like std.bitmanip.taggedClassRef should have a big warning on it, right? Thanks
OK to do bit-packing with GC pointers?
I'm looking to store a pointer to one of 2 unrelated (no
inheritance relationship) classes and use the LSb to track which
type I have. Is this going to cause any problems with the GC?
For one of the classes I'll have a "pointer" to 1 byte past the
start of the object. It seems like std.bitmanip.taggedClassRep
does something similar, so I assume it's OK, but wanted to double
check.
Here's the type:
```
struct EitherClass(C1, C2) if (is(C1 == class) && is(C2 ==
class)){
private size_t data;
public:
@safe:
@nogc:
nothrow:
this(C1 c1) @trusted {
data = cast(size_t)(cast(void*)(c1));
}
this(C2 c2) @trusted {
data = cast(size_t)(cast(void*)(c2));
data |= 1;
}
typeof(this) opAssign(C1 c1) @trusted {
data = cast(size_t)(cast(void*)(c1));
return this;
}
typeof(this) opAssign(C2 c2) @trusted {
data = cast(size_t)(cast(void*)(c2));
data |= 1;
return this;
}
bool holds(C)() const if(is(C == C1) || is(C == C2)){
static if(is(C == C1)){
return (data & 1) == 0;
} else {
return (data & 1) != 0;
}
}
auto get(C)() const @trusted if(is(C == C1) || is(C == C2)) {
static if(is(C == C1)){
assert(holds!C1);
return cast(C1)(cast(void*)(data));
} else {
assert(holds!C2);
return cast(C2)(cast(void*)(data & ~(1UL)));
}
}
}
```
Re: Trait for "can be instantiated"?
On Wednesday, 11 May 2022 at 12:29:05 UTC, Basile B. wrote:
How about being more explicit in the UDA ?
The idea would be to associate the enum value to a type or not:
I think that could work but would require some major changes to
my existing code. Also, I think I'd prefer:
```
@Token{
enum lparen = '(';
enum rparen = ')';
enum if_token;
}
```
to what you suggested as a user of the library.
Re: Trait for "can be instantiated"?
On Tuesday, 10 May 2022 at 16:05:15 UTC, H. S. Teoh wrote: Using wrapper structs, etc., for this is IMO total overkill. Just use an enum for your token types. Something like this would suffice: That's basically what sumtype is going to do for me, but (hopefully) more safely. Also, the token types are "user defined," my lexer just grabs everything annotated with @Token and passes those types/wrapped enums to sumtype.
Re: Trait for "can be instantiated"?
On Tuesday, 10 May 2022 at 05:45:25 UTC, ag0aep6g wrote:
`x` is a type, period.
You can use void initialization to declare values of types that
don't have an `init` value: `x value = void;`
As for an alternative to the brute force `__traits(compiles,
...)`, you can check if `T.init` is a thing:
static if (is(typeof(T.init))) { T value; }
I'm not sure if that's really better, though.
By the way, what is your `Wrap` supposed to do with `x`?
Treating it like `y` will likely fail, too, because `x` is not
a value.
I'm writing a lexer and I'm using sumtype to store any of the
token types. Some have values associated with them (like
brackets and parens which are defined as `enum lparen = '('` or
whatever) and some are just markers (keywords like 'if', which
I'm trying to represent with just `enum if_token` ). The wrapper
struct is there because I need a type for each one to use them as
part of a sumtype and I only want to store the enum's value when
it makes sense to.
Re: Trait for "can be instantiated"?
On Monday, 9 May 2022 at 21:58:59 UTC, Ali Çehreli wrote:
On 5/9/22 14:24, Ben Jones wrote:
> Is there a trait that can tell if you
> can initialize a variable of a certain type?
Not answering that question but the 'is' expression seems to
work in this case:
static if(is (T)) {
T value;
}
https://dlang.org/spec/expression.html#IsExpression
Ali
Using is(T) instead of isType!T also appears to be true for the
un-instantiate-able enum. Was your point just that I could
replace isType!T with is(T)?
Trait for "can be instantiated"?
I have a struct template that takes an alias parameter and I'm
trying to distinguish between type parameters and enum values.
std.traits.isType works for this except for one edge case:
```
import std.traits;
import std.stdio;
struct S{}
enum x;
enum y = 5;
struct Wrap(alias T) {
static if(isType!T){
T value; //When t == x this doesn't work because `x` is
opaque and has no default initializer
}
}
void main()
{
pragma(msg, isType!x); //true
pragma(msg, isType!y); //false
Wrap!S ws; //OK
Wrap!x wx; //error instantiating
Wrap!y wy; //OK, because we the static if condition is false
}
```
x is a "type" as far as isType is concerned (which makes sense to
me), but I don't think you can ever declare a variable of that
type since there's no way to initialize it... Is there a trait
that can tell if you can initialize a variable of a certain type?
The best I can think of is __traits(compiles, "T x;"), but it
seems like it should be possible to do better?
Re: Libc functions undefined when linking
On Wednesday, 5 January 2022 at 03:38:54 UTC, Tejas wrote: On Tuesday, 4 January 2022 at 18:13:56 UTC, Ben Jones wrote: The tricky part is that the lab machines that the students will be using don't have a D compiler installed (they're Fedora machines, and I didn't see a dmd package in their repos, or I would have asked the admins to install it). I'm using Fedora 34 `sudo dnf install ldc` works and gives ldc version 1.25.0(based on dmd 2.095.1)(but you invoke via `ldc2` or `ldmd2`) name of rpm: Source : ldc-1.25.1-2.fc34.src.rpm `sudo dnf install gcc-gdc` also works(but it's not the recent one with the D frontend)(you don't even need to write `gdc .d`, `gcc .d` also works.) name of rpm: Source : gcc-11.2.1-1.fc34.src.rpm good to know. What about dub?
Re: Libc functions undefined when linking
On Tuesday, 4 January 2022 at 21:34:46 UTC, Adam D Ruppe wrote: On Tuesday, 4 January 2022 at 21:22:26 UTC, Ben Jones wrote: * frame #0: 0x That's null, meaning the library wasn't loaded. simpledisplay actually doesn't need -lX11 since it always dynamic loads the libraries. Normally it throws when this fails though instead of keeping null but that check is also initialized in a static constructor With your different build process though, do you still have a D main? If druntime is not fully initialized these libs won't load nor will it set the success flag. So that'd leave null. You can also quite possibly try to load it yourself: xlib.loadDynamicLibrary(); xext.loadDynamicLibrary(); in your main and see if it works. Then the variable to check is `if(!librariesSuccessfullyLoaded)` and see if it set it up. Ah, that was the issue. I had a linker error when I had a normal d main, so I made main `extern(C)`. Looks like that wasn't actually necessary (I think maybe I had actually just put the .o with main in the wrong place so the symbol was missing). Reverting it to extern(D) fixed it on mac and linux. Thanks so much for the help!
Re: Libc functions undefined when linking
On Tuesday, 4 January 2022 at 20:28:00 UTC, Ben Jones wrote: On Tuesday, 4 January 2022 at 19:14:04 UTC, Adam D Ruppe wrote: [...] Crashes on `display = XOpenDisplay(displayName);` : ``` * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x frame #1: 0x00010005180d gameboy`_D4arsd13simpledisplay18XDisplayConnection3getFZPSQBwQBu7Display at simpledisplay.d:12572 frame #2: 0x0001000470e0 gameboy`_D4arsd13simpledisplay5Image4impl11createImageMFiibbZv(this=0x00010120, enableAlpha=false, forcexshm=false, height=144, width=160) at simpledisplay.d:12678 frame #3: 0x000100046bcc gameboy`_D4arsd13simpledisplay5Image6__ctorMFiibbZCQBpQBnQBb(this=0x00010120, enableAlpha=false, forcexshm=false, height=144, width=160) at simpledisplay.d:7065 [...] Hmm, I get the same segfault on linux, I'm linking with these flags and I the only warnings I get are about unwinding offsets: `clang build/*.o -L. -lphobos2 -lX11 -ldl -lpthread -o build/gameboy`
Re: Libc functions undefined when linking
On Tuesday, 4 January 2022 at 19:14:04 UTC, Adam D Ruppe wrote: On Tuesday, 4 January 2022 at 19:10:25 UTC, Ben Jones wrote: All good, except now simpledisplay is segfaulting on XDisplayConnection.get again run it in the debugger; do a -g build and run it in gdb or lldb and do check the exact line it is on. could be that the Xlib things didn't dynamically load. I thought I tested that but could have missed a spot and Apple has a bad habit of movign things so who knows. Crashes on `display = XOpenDisplay(displayName);` : ``` * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x frame #1: 0x00010005180d gameboy`_D4arsd13simpledisplay18XDisplayConnection3getFZPSQBwQBu7Display at simpledisplay.d:12572 frame #2: 0x0001000470e0 gameboy`_D4arsd13simpledisplay5Image4impl11createImageMFiibbZv(this=0x00010120, enableAlpha=false, forcexshm=false, height=144, width=160) at simpledisplay.d:12678 frame #3: 0x000100046bcc gameboy`_D4arsd13simpledisplay5Image6__ctorMFiibbZCQBpQBnQBb(this=0x00010120, enableAlpha=false, forcexshm=false, height=144, width=160) at simpledisplay.d:7065 ``` Which makes lots of sense because: "On a POSIX-conformant system, if the display_name is NULL, it defaults to the value of the DISPLAY environment variable." (https://www.x.org/releases/X11R7.5/doc/man/man3/XOpenDisplay.3.html) (/sarcasm) Explicitly calling setDisplayName before I try to use the display didn't make a difference, so maybe it's assignment to display that's causing the segfault? Not sure why that would cause a segfault either
Re: Libc functions undefined when linking
On Tuesday, 4 January 2022 at 18:45:37 UTC, Ben Jones wrote: On Tuesday, 4 January 2022 at 18:37:25 UTC, Adam D Ruppe wrote: On Tuesday, 4 January 2022 at 18:13:56 UTC, Ben Jones wrote: clang -c -o source/assignment1.o source/assignment1.c you might have better luck just telling clang to link it too like clang source/assignment1.o -lphobos2 build/*.o # etc since there's a bunch of default search paths and libs etc the compiler pass to the linker. otherwise if you do need to use the linker directly worth remembering the order of args matter too. you need to put the more derived dependencies first followed by more general ones at the end Using clang seems to work better. It sounds like Apple basically hides system libraries since Big Sur, and I guess their clang knows the magic flags to pass to find them. Thanks! All good, except now simpledisplay is segfaulting on XDisplayConnection.get again (you helped me before by specifying a DISPLAY environment variable, but that's not working now, with either :0 or the longer value set by xquartz when opening an xterm). I'm not sure how it can segfault since there are null checks in that method... maybe I should just head to the linux lab and stop fighting Apple.
Re: Libc functions undefined when linking
On Tuesday, 4 January 2022 at 18:37:25 UTC, Adam D Ruppe wrote: On Tuesday, 4 January 2022 at 18:13:56 UTC, Ben Jones wrote: clang -c -o source/assignment1.o source/assignment1.c you might have better luck just telling clang to link it too like clang source/assignment1.o -lphobos2 build/*.o # etc since there's a bunch of default search paths and libs etc the compiler pass to the linker. otherwise if you do need to use the linker directly worth remembering the order of args matter too. you need to put the more derived dependencies first followed by more general ones at the end Using clang seems to work better. It sounds like Apple basically hides system libraries since Big Sur, and I guess their clang knows the magic flags to pass to find them. Thanks!
Re: Libc functions undefined when linking
On Tuesday, 4 January 2022 at 18:26:41 UTC, Ali Çehreli wrote: On 1/4/22 10:13 AM, Ben Jones wrote: > So I think I need to specify that I want to explicitly include libc when > I link it. `-lc` didn't seem to work. Did you add -lc and -lpthread on the linker line? > ld build/*.o -L. -lphobos2 -o build/executable Ali Maybe it's a mac thing and that will work when I get to linux, but I did try that and ld couldn't find the lib: ``` ld: library not found for -lc ``` Same result for -lpthread, and for -pthread (no l)
Libc functions undefined when linking
I have a somewhat unusual use case and I'm having trouble getting everything to link properly. I'm writing an assignment for a course I'm teaching and I've written the skeleton code in D, and students are going to implement one function in C, which my skeleton code will call. The tricky part is that the lab machines that the students will be using don't have a D compiler installed (they're Fedora machines, and I didn't see a dmd package in their repos, or I would have asked the admins to install it). I plan to distribute compiled .o files for all the d modules, along with a static libphobos. The students can compile their C file, and then link everything together. I haven't tested it on the linux machines yet, but developing it on my mac, I'm getting undefined symbols for libc and pthread functions from libphobos: ``` "_thread_suspend", referenced from: __D4core6thread8osthread7suspendFNbNiCQBjQBhQBd6ThreadZb in libphobos2.a(osthread_8db_302.o) (maybe you meant: _thread_suspendAll) "_tmpfile", referenced from: __D3std5stdio4File7tmpfileFNfZSQBcQBbQy in libphobos2.a(stdio_d42_180.o) "_toupper", referenced from: __D2rt6config16rt_envvarsOptionFNbNiAyaMDFNbNiQkZQnZQq in libphobos2.a(config_94b_6c3.o) "_waitpid", referenced from: __D4core8internal2gc2os8wait_pidFNbNiibZEQBmQBkQBeQBe11ChildStatus in libphobos2.a(os_610_351.o) ``` So I think I need to specify that I want to explicitly include libc when I link it. `-lc` didn't seem to work. Anyone how the right way to do so? Here are the steps I'm doing. I'll compile all the D stuff myself, and distribute the .o files with my assignment, and they'll just be doing the C compilation and linking steps. ``` dmd -c -I=source -of=build/simpledisplay.o source/arsd/simpledisplay.d dmd -c -I=source -of=build/color.o source/arsd/color.d dmd -c -I=source -of=app.o source/app.d clang -c -o source/assignment1.o source/assignment1.c ld build/*.o -L. -lphobos2 -o build/executable ```
Re: Struct fields and properties as alias members
On Wednesday, 8 December 2021 at 18:23:25 UTC, Adam D Ruppe wrote: On Wednesday, 8 December 2021 at 18:07:32 UTC, Ben Jones wrote: I went with the mixin approach, which seems to work fine except that I couldn't declare the mixin inside a function, so the definition is pretty far away from use, but that's not a showstopper. Thanks for your excellent explanations + suggestions
Re: Struct fields and properties as alias members
On Wednesday, 8 December 2021 at 17:44:47 UTC, Adam D Ruppe wrote: On Wednesday, 8 December 2021 at 17:19:32 UTC, Ben Jones wrote: Gotcha, thanks. I tried using `S.field` before and that didn't work, `__traits(child)` was the key. Since I reuse the field a few times I tried to alias the result: `alias theProp = __traits(child, s, field);` But everywhere I use `theProp` I get the same error as before (need this...). Is there a way to avoid using the full `__traits(child)` expression everywhere?
Re: Struct fields and properties as alias members
On Wednesday, 8 December 2021 at 17:29:19 UTC, H. S. Teoh wrote:
On Wed, Dec 08, 2021 at 05:19:32PM +, Ben Jones via
Digitalmars-d-learn wrote:
I'm trying to use a property member of a struct as a template
alias parameter and I don't really understand how to fix the
error message I'm seeing (I also tried the simpler case of a
plain struct member, and that didn't work either). Is what
I'm trying to do possible? It seems like maybe I'd have to
pass s as a runtime parameter to get it to work?
It might help if you elaborate a bit more on what exactly
you're trying to achieve here. Why can't you just pass the
value of the field to the function as a runtime parameter, for
example, which would be the usual way of doing it? Is there
something specific you're trying to achieve here that requires
using a template parameter?
T
It's a CPU simulator and the function needs to operate on half of
a register (the CPU has 16 bit AF register, but I want to operate
on A). I've implemented the "A" part of the register as a pair
of property functions:
```
@property ubyte a() const { return getHigh!af; }
@property ubyte a(ubyte val) { return setHigh!af(val); }
```
There are CPU instructions for each of the combined (AF, BC, DE,
etc) and half(A, B, C, D, E, etc) registers, so I think either
the half registers or the full registers would have to be
implemented as property functions (from my reading of the spec,
using unions seemed like technically it would be UB?)
Basically I want to write one template for the operation
(increment, load, etc), and then instantiate it for each register
(inc a, inc b, inc c, load a, load b, etc)
Re: Struct fields and properties as alias members
On Wednesday, 8 December 2021 at 17:19:32 UTC, Ben Jones wrote: I considered just having a `ref int` parameter, but I didn't think that would work if I was actually calling a property function, rather than just modifying a struct member. I also tried to use a template mixin, but couldn't get that to work either.
Struct fields and properties as alias members
I'm trying to use a property member of a struct as a template
alias parameter and I don't really understand how to fix the
error message I'm seeing (I also tried the simpler case of a
plain struct member, and that didn't work either). Is what I'm
trying to do possible? It seems like maybe I'd have to pass s as
a runtime parameter to get it to work?
```
import std.stdio;
struct S{
int a = 1;
int b = 2;
@property int c(){ return a; }
@property int c(int newc) { a = newc; return a;}
}
void func(alias field)(){
writeln(field);
field = 5;
}
void main(){
S s;
func!(s.a)();
func!(s.b)();
func!(s.c)();
}
```
Runnable link here: https://run.dlang.io/is/WHM1Er
Errors:
```
onlineapp.d(17): Error: need `this` for `func` of type `@safe
void()`
onlineapp.d(18): Error: need `this` for `func` of type `@safe
void()`
onlineapp.d(12): Error: need `this` for `c` of type `@property
int()`
onlineapp.d(13): Error: need `this` for `c` of type `@property
int(int newc)`
onlineapp.d(20): Error: template instance `onlineapp.func!(c)`
error instantiating
```
Re: arsd.simpledisplay on macos
On Tuesday, 16 November 2021 at 14:38:47 UTC, Adam Ruppe wrote: 1) run xquartz separately to ensure it is up 2) set hte DISPLAY=:0 environment variable before starting the sdpy app Adding DISPLAY:0 fixed it, thanks. If I get time, I'll take a look at the objective C stuff, but that's a big if.
arsd.simpledisplay on macos
I'm trying to use Adam's simpledisplay on a mac with XQuartz which is installed + running. When I try to create a window, it crashes when calling `XDisplayConnection.get()`. I'm just building dub and have added `"arsd-official:simpledisplay"` as a dependency. Before I installed XQuartz, it wouldn't link because of the X related libs missing, so the XQuartz libs did seem to get installed to the right place. The native cocoa implementation seemed less well tested than the X version so I haven't looked into that too much. Any idea what's going wrong? Or is there an example that seems to work with the native cocoa version? I'm only planning to use really basic functionality (display an image and maybe capture some key presses) Also, Adam, if you have an idea of what needs to be done to get native macos support working, I'm willing to try to give it a shot. ``` object.Exception@../../../.dub/packages/arsd-official-10.3.8/arsd-official/simpledisplay.d(12578): Unable to open X display ../../../.dub/packages/arsd-official-10.3.8/arsd-official/simpledisplay.d:12578 arsd.simpledisplay.Display* arsd.simpledisplay.XDisplayConnection.get() [0x10f49cc8e] ../../../.dub/packages/arsd-official-10.3.8/arsd-official/simpledisplay.d:13072 void arsd.simpledisplay.SimpleWindow.impl.createWindow(int, int, immutable(char)[], in arsd.simpledisplay.OpenGlOptions, arsd.simpledisplay.SimpleWindow) [0x10f4882ec] ../../../.dub/packages/arsd-official-10.3.8/arsd-official/simpledisplay.d:1688 arsd.simpledisplay.SimpleWindow arsd.simpledisplay.SimpleWindow.__ctor(int, int, immutable(char)[], arsd.simpledisplay.OpenGlOptions, arsd.simpledisplay.Resizability, arsd.simpledisplay.WindowTypes, int, arsd.simpledisplay.SimpleWindow) [0x10f486017] source/app.d:869 _Dmain [0x10f47dff2] Program exited with code 1```
Public and private versions of opIndex
I have a struct which I would like to have a public opIndex which
returns by value (so client code can't modify my internal array),
and a private version which allows the implementing code to
modify stuff with `this[whatever] = whatever`.
I tried to to write 2 versions of opIndex:
```
public Type opIndex(IndexType x) const {... }
//and
private Type ref opIndex(IndexType x) { ... }
```
which doesn't seem to work because client code that has a
non-const reference to my container tries to use the private
non-const version and triggers a `not accessible` error. Is
there a way to do this with overloads, or will I need to just
pick a different name for the private version?
type suffix for character literal
Are there suffices (suffixes?) for character literals?
Is there a more succinct of writing "the literal 'x' as a dchar"
than dchar('x')?
I didn't see anything
https://dlang.org/spec/lex.html#characterliteral but figured I'd
ask the community
Re: IsTuple returns true for Nullable!SomeTuple
On Wednesday, 2 December 2020 at 12:59:52 UTC, Paul Backus wrote: No, this is not a bug, because Nullable!T currently has an implicit conversion to T via `alias this`. [1] However, this implicit conversion is deprecated, and will be removed in a future release. Once that happens, `isTuple!NT` will be `false`, as you'd expect. [1] http://phobos.dpldocs.info/std.typecons.Nullable.1.html#alias-this I guess it's a moot point because the implicit conversion is deprecated, but it seems strange to me that isTuple behaves like canBeUsedAsTuple. Seems like the reasonable thing to do with a Nullable!(Tuple!Whatever) would be to check isTuple!(TemplateArgsOf!MyNullable) Thanks for the response
IsTuple returns true for Nullable!SomeTuple
This seems like very surprising behavior to me. Is it a bug? import std.typecons; alias NT = Nullable!(Tuple!(int, double)); pragma(msg, isTuple!NT); //prints true!
Re: Variadic function template with one inferred template argument
On Saturday, 7 November 2020 at 21:04:19 UTC, starcanopy wrote:
void main() {
f!(int, float, char)("Hello, world!");
}
https://run.dlang.io/is/e8FGrF
Ah, I had discovered a different error when I tried that. Thanks!
Variadic function template with one inferred template argument
I'm trying to write a function template with 1 parameter whose
type is inferred, but with the other parameters variadic.
Basically, I want to do this:
auto f(Ts..., Inferred)(Inferred inf){}
and call it with f!(X,Y,Z)(w) //inferred will be typeof(w), Ts...
== (X, Y, Z)
which I can't do because the variadic template args have to come
last.
Is there a way to change f so that the caller can use it like I
want? I tried this approach which didn't work.
template f(Ts...){
auto f(Inferred)(Inferred inf){}
}
I don't see a way to specify a variadic set of template args but
have one inferred. I could wrap the variadic args in another
template so f just takes 2 params, but I'd like to avoid that
because it makes the calling code more complicated.
Re: Deprecation in traits
On Wednesday, 30 September 2020 at 18:18:48 UTC, Basile B. wrote: On Tuesday, 29 September 2020 at 17:08:40 UTC, Frak wrote: Hi folks, I've this: /Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711): Deprecation: function `std.typecons.Nullable!long.Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions? The problem has been observed already and it is an official enhancement request [1]. I think it is legit because deprecation are sometimes used to help into refactoring, so to have the use site is a essential. [1] https://issues.dlang.org/show_bug.cgi?id=21176 Does compiling with -v help? I think it might at least show you which module the issue is coming from?
Re: Template argument deduction fails with alias
On Tuesday, 1 September 2020 at 01:26:30 UTC, Paul Backus wrote:
Aside from using SumType directly in the function signature,
another workaround is to use a wrapper struct instead of an
alias:
struct AliasType(Args...) {
SumType!Args data;
alias data this;
}
bool func(T : AliasType!Args, Args...)(T t) { ... }
Thanks all.
I tried using alias this at first and then I get errors trying to
construct AliasType objects:
auto pi = Payload!int(5);
auto pe = ParseError("error");
alias PRType = ParseResult!(Payload!int, ParseError);
auto pr = PRType(pi);
gives:
cannot implicitly convert expression `pi` of type `Payload!int`
to `SumType!(Payload!int, ParseError)`
Template argument deduction fails with alias
I have an alias that looks like
static if(...){
alias AliasType = SumType!(...);
}
which I use in a template constraint for a function template:
bool func(T: AliasType!Args, Args...)(T t){ ... }
When I try to call func with an AliasType object, the argument
deduction fails with a message saying that the argument type (a
SumType) doesn't match the template constraint (an AliasType)
Things do work if I change the template constraint to be a
SumType rather an an AliasType
Is there a workaround to this? Here's a complete example:
https://run.dlang.io/is/buRGTs
Re: Error: `std.uni.isUpper` conflicts with `std.ascii.isUpper`
On Tuesday, 14 July 2020 at 20:37:53 UTC, Marcone wrote:
import std: isUpper, writeln;
void main(){
writeln(isUpper('A'));
}
Why I get this error? How can I use isUpper()?
import std.uni: isUpper; // or import std.ascii : isUpper
import std.stdio : writeln;
import std pulls in all the modules in phobos and uni and ascii
both contain functions named isUpper. There's probably many ways
to fix the error, but I usually import the modules I want
explicitly.
Re: Surprising interaction of tuples and slicing
On Thursday, 7 May 2020 at 23:07:40 UTC, Ali Çehreli wrote: The trouble seems to be when slicing the entire tuple. Even in that case, printing a warning would not be desired in some situations ironically in generic code where e.g. T[0..$] may appear, which is the same as T[]. Ali I agree T[0..$] and T[] mean the same thing and the first could come up naturally, but if there's never a useful cased spelled with T[], then it would be detectable and nice to issue a warning.
Re: variant visit not pure?
On Thursday, 7 May 2020 at 14:53:10 UTC, Steven Schveighoffer wrote: As others have recommended, I suggest using TaggedAlgebraic. I recently have been using it to create an algebraic type to hold a MYSQL value, so I can migrate the mysql-native library to be @safe (mysql-native currently uses Variant for everything). -Steve I've been using SumType... What are the main differences between it and TaggedAlgebraic?
Surprising interaction of tuples and slicing
I was doing some metaprogramming where I wanted to make a slice of a type: alias Tbasic = int; pragma(msg, Tbasic); alias Tbasica = Tbasic[]; pragma(msg, Tbasica); //prints int, int[] And things worked fine until I attempted the same thing on what happened to be a tuple of 1 element: alias Ts = AliasSeq!int; pragma(msg, Ts); alias Tsa = Ts[]; pragma(msg, Tsa); //prints (int), (int) which confused me until I realized that the [] was slicing the tuple. Note, you can add as many [] as you want since it's basically a no-op. pragma(msg, Ts[0][]); //prints int[] Is there any use for this behavior? It seems like it might be worth warning like "slicing a tuple is a no-op" Anyway, figured I'd post here for posterity since I was confused by it for a while.
Re: Idomatic way to guarantee to run destructor?
On Thursday, 30 April 2020 at 16:55:36 UTC, Robert M. Münch wrote:
For ressource management I mostly use this pattern, to ensure
the destructor is run:
void myfunc(){
MyClass X = new MyClass(); scope(exit) X.destroy;
}
I somewhere read, this would work too:
void myfunc(){
auto MyClass X = new MyClass();
}
What does this "auto" does here? Wouldn't
void myfunc(){
auto X = new MyClass();
}
be sufficient? And would this construct guarantee that the
destructor is run? And if, why does "auto" has this effect,
while just using "new" doesn't guarantee to run the destructor?
I think you want to use scope rather than auto which will put the
class on the stack and call its destructor:
https://dlang.org/spec/attribute.html#scope
Structs containing mutually referential sumtypes
I'm trying to define some structs that contain sumTypes (using
the sumtype library) that refer to each other, but I get a
recursive template instantiation error. It looks like typically
recursion is handled in that library with the This type, but I
don't see how that would apply here. Any advice on how to get
this to work?
```
struct Terminal{
string name;
}
struct Op(string op){
alias ElemType = SumType!(Terminal, Term);
ElemType[] elems;
}
struct Term{
alias ElemType = SumType!(Op!"+", Op!"-", Op!"*", Terminal);
ElemType[] elems;
}
```
Errors with
```
Error: template instance SumType!(Op!"+", Op!"-", Op!"*",
Terminal) recursive template expansion
../../../.dub/packages/sumtype-0.9.4/sumtype/src/sumtype.d(331,14): Error:
template instance std.traits.isCopyable!(Term) error instantiating
source/errorbound/tracked.d(25,20):instantiated from
here: SumType!(Terminal, Term)
source/errorbound/tracked.d(31,29):instantiated from
here: Op!"+"
/usr/local/opt/dmd/include/dlang/dmd/std/meta.d(839,24): Error:
template instance core.internal.traits.allSat!(isCopyable,
Terminal, Term) error instantiating
```
static foreach over enum symbols
Hi all,
I'm getting unexpected results while trying to process symbols
from a module, some of which are enums.
Depending on whether or not I comment out the first static
foreach loop below, fullyQualifiedName gives me different results
in the second loop.
In either case, I'm surprised I can't grab the UDAs in the second
static foreach loop. Any ideas what's going on?
Test case:
---a.d---
module a;
@Object
enum x = "hello";
@Object
enum y = "goodbye";
@Object
struct z{}
---main.d---
template symbols(alias Mod){
import std.meta;
alias toSymbol(alias T) = __traits(getMember, Mod, T);
alias symbols = staticMap!(toSymbol, __traits(allMembers,
Mod));
}
void main(){
import std.traits;
import std.meta;
import a;
//commenting this out changes the results below
static foreach(sym; symbols!a){
pragma(msg, fullyQualifiedName!sym);
pragma(msg, __traits(getAttributes, sym));
}
pragma(msg, "\nget with UDAs\n");
pragma(msg, getSymbolsByUDA!(a, Object));
alias udaSyms = getSymbolsByUDA!(a, Object);
pragma(msg, staticMap!(fullyQualifiedName, udaSyms));
static foreach(us; udaSyms){
pragma(msg, fullyQualifiedName!us);
pragma(msg, __traits(getAttributes, us));
}
}
---
annotated output of dmd main.d:
with the first loop commented out:
get with UDAs
tuple("hello", "goodbye", (z))
tuple("a.x", "a.y", "a.z")
a.x
tuple() //why is the UDA gone?
a.y
tuple()
a.z
tuple((Object))
and with the first loop:
object
tuple()
main.main.sym //it's not a.x anymore, it's the name of the local
var for static foreach?
tuple()
main.main.sym
tuple()
a.z
tuple((Object))
get with UDAs
tuple("hello", "goodbye", (z))
tuple("main.main.sym", "main.main.sym", "a.z") //and the results
are changed here too?
main.main.sym
tuple()
main.main.sym
tuple()
a.z
tuple((Object))
Unexpected result of IsInstanceOf
The following result doesn't make sense to me... how does
isInstanceOf return false?
```
import std.traits;
import std.stdio;
import std.typecons;
auto f(T)(T t){
return Nullable!T(t);
}
void main(){
auto f3 = f(3);
writeln(typeof(f3).stringof);
writeln(isInstanceOf!(Nullable, f3));
}
```
outputs
```
Nullable!int
false
```
Re: Easiest way to use FMA instruction
On Friday, 10 January 2020 at 00:08:44 UTC, Johan wrote:
On Friday, 10 January 2020 at 00:02:52 UTC, Johan wrote:
[...]
You have to tell LDC that you are compiling for a CPU that has
FMA capability (otherwise it will insert a call to a "fma"
runtime library function that most likely you are not linking
with). For example, "-mattr=fma" or "-mcpu=skylake".
https://d.godbolt.org/z/ddwORl
Or you add it only for the "fma" function, using
```
import ldc.attributes;
@target("fma") double fma(double a, double b, double c) ...
```
https://d.godbolt.org/z/-X7FnC
https://wiki.dlang.org/LDC-specific_language_changes#.40.28ldc.attributes.target.28.22feature.22.29.29
cheers,
Johan
I need it for the rounding behavior. Thanks for the pointers,
that's very helpful.
Re: Easiest way to use FMA instruction
On Thursday, 9 January 2020 at 20:57:10 UTC, Ben Jones wrote:
What's the easiest way to use the FMA instruction (fused
multiply add that has nice rounding properties)? The FMA
function in Phobos just does a*b +c which will round twice.
Do any of the intrinsics libraries include this? Should I
write my own inline ASM?
This seems to work with DMD, but seems fragile:
`
///returns round(a*b + c) -- computed as if in infinite
precision, rounded at the end
double fma(double a, double b, double c) @safe pure @nogc nothrow{
asm @safe pure @nogc nothrow {
naked;
vfmadd231sd XMM0, XMM1, XMM2;
ret;
}
}
`
Easiest way to use FMA instruction
What's the easiest way to use the FMA instruction (fused multiply add that has nice rounding properties)? The FMA function in Phobos just does a*b +c which will round twice. Do any of the intrinsics libraries include this? Should I write my own inline ASM?
Re: Getting all types defined in a module at compile time
On Tuesday, 19 November 2019 at 01:55:17 UTC, Paul Backus wrote:
On Monday, 18 November 2019 at 21:48:00 UTC, Ben Jones wrote:
template notmodule(alias T){
alias notmodule = __traits(isModule, T);
}
[...]
I get errors:
```
(on the alias notmodule line) Error: trait isModule is either
invalid or not supported in alias
```
The result of __traits(isModule, T) is a boolean value, so the
line should be
enum notmodule = __traits(isModule, T);
Thanks!
Is there a good resource on D metaprogramming somewhere? I'm
kind of stumbling my way through things and would love to see
some best practices laid out somewhere.
Getting all types defined in a module at compile time
I'm trying to get a list of all the types defined in a module at
compile time (enums, structs, classes). I attempted to use the
isAggregateType trait, but it choked when it was passed modules
that had been imported (object, and the others explicitly
imported).
My next attempt was to try to filter out the modules, then look
at everything left over with things like isAggregateType, etc.
However, I'm getting errors when trying to filter on isModule.
Am I missing out on a simpler/more direct approach? Is there a
workaround to this alias error?
```
module thismodule;
import std.meta;
import std.traits;
struct S{}
enum E {asdf};
class C{}
template symbols(alias mod){
alias getSymbol(alias T) = __traits(getMember, mod, T);
alias symbols = staticMap!(getSymbol, __traits(allMembers,
mod));
}
template notmodule(alias T){
alias notmodule = __traits(isModule, T);
}
void main(){
static foreach(s; symbols!thismodule){
pragma(msg, fullyQualifiedName!s);
}
alias notmods = Filter!(templateNot!notmodule,
symbols!thismodule);
}
```
I get errors:
```
(on the alias notmodule line) Error: trait isModule is either
invalid or not supported in alias
```
Pass field as a template parameter
I'm trying to write a template function like the below... is it
possible without using string mixins?
void fun( alias(?) field, alias p1, alias p2)()
{
if(p1.field)
use(p2.field);
}
called with something like
static foreach( list of fields){
fun!(field, p1, p2)();
}
I have no idea how to specify the list of fields and I'm not sure
if alias is the right "type" for the field template parameter.
Dummy template parameter vs empty template parameter list
Looking through Phobos code there's a bunch functions defined with dummy template types: void whatever(TDummy = void)( int x, ...) //TDummy is never used Why not just use an empty template parameter list? void whatever()(int x, ...) My gut tells me that his is a workaround for an old limitation preventing empty template lists, but figured I'd ask.
