Re: misc questions about a DUB package
On Wednesday, 15 July 2020 at 11:49:09 UTC, Jacob Carlborg wrote: The plus sign and anything after is ignored by Dub. Good to know, thank you.
Re: misc questions about a DUB package
Thank you.
misc questions about a DUB package
I have some D-wrapped C libraries I'm considering publishing to DUB, mainly for my own use but also for anybody else who might benefit. I've never done this before so I have some questions: - Should there be any obvious relationship between the DUB package version and the version of the C library? What are the best practices for connecting the two, if at all? - I'm very much about the "full fat" D experience, so I presently have no intention of designing my D wrappers for betterC/the-runtime-is-lava usage. That being the case, is there any compelling reason to avoid initializing the C library in a 'shared static this()' method? (ie automatically)
Re: Pattern matching via switch?
I've been playing around with this via inheritance lately (I'm
aware of the sumtype package but specifically wanted to use
objects instead of structs), had some good results.
It involves a bit of boilerplate though. I'm essentially using
the visitor pattern + an anonymous class implementing a matcher
interface:
https://gist.github.com/dewf/dadc0f2775b40b65a3ebf7458d3c2c79
I would love to use templated return values from the match()
method, though. Does anybody know how to do that without the
compiler complaining ("'final' functions cannot be 'abstract'") ?
Specifically, is there any way to make:
abstract void match(Matcher m);
Become:
abstract T match(T)(Matcher!T m);
?
Re: dub dustmite struggles
On Monday, 20 January 2020 at 15:04:32 UTC, Andre Pany wrote: In general dub Dustmite works fine, I used it several times. Maybe it has to do s.th. with your project structure. Please create a dub issue with an example zip. I've created a minimal nested project with a similar structure (library with nested app project), and dub-dustmite works fine there. So it must be something peculiar to my real project. Once the standalone dustmite finishes running, I'll spend some time manually reducing my project structure to something repeatable to file an issue with. Thanks!
Re: dub dustmite struggles
On Monday, 20 January 2020 at 07:14:24 UTC, FeepingCreature wrote: dustmite example ../test.sh Right, that's what I'm already doing now. However, the process is extremely slow (takes 10+ hours for the current project, when I've done this in the past) so I am hoping to speed things up a bit by using dub's dustmite directly (vs. the test script invoking dub anew on each run).
dub dustmite struggles
I can't seem to figure out what dub's dustmite command is looking for with its regexes. No matter what I try - no matter how simple - the initial test fails. I am able to run dustmite standalone just fine with the following test script: cd example dub 2>&1 | grep -F "ScrollView6__initZ+0xd8): undefined reference to \`internal'" However, when I attempt using 'dub dustmite' with --linker-regex (or --linker-status, even), the initial test always fails. I've also tried simplifying the regex on the assumption that I'm not escaping things properly - to no avail. Is it perhaps something to do with my project structure? My project is a library containing an /example subfolder, containing an application dub project, and that's where my linker error occurs, not in the library itself. So that's where I'm attempting to run dub dustmite as well.
Re: needing to change the order of things at module level = compiler bug, right?
On Thursday, 12 December 2019 at 06:23:31 UTC, Basile B. wrote: Still worth opening an issue. https://issues.dlang.org/show_bug.cgi?id=20443 Thanks, Basile. I've added additional information from the github thread where the sumtype author helpfully looked into the problem.
Re: needing to change the order of things at module level = compiler bug, right?
On Sunday, 8 December 2019 at 18:01:03 UTC, Steven Schveighoffer wrote: Yes, if it can compile when you move things around, and the result is *correct* (very important characteristic) Indeed, everything's working as intended when rearranged. Thanks!
needing to change the order of things at module level = compiler bug, right?
I dustmite'd down my problem code, and it seems just changing the
order of declarations makes the error go away. Specifically,
moving a class declaration from the bottom of the file, to the
top, allows it to compile. I also commented on two other things
that can be changed to make it work - neither seemingly related
to the error at hand.
Just double-checking before I file a bug for this:
--
import sumtype;
// DMD 2.089.0-dirty (also v2.087.1)
// app.d(18,13): Error: struct
sumtype.SumType!(CallbackType1).SumType is not copyable because
it is annotated with @disable
struct Struct1(T) {
bool[T] items;
}
struct CallbackType1 {
void delegate(Struct1!Class2) func; // changing arg to
Class2[] compiles OK
}
alias CallbackType = SumType!CallbackType1;
class Class1 {
CallbackType _callback;
this(CallbackType callback) { // commenting out this ctor
compiles OK
_callback = callback;
}
}
// moving Class2 to the top of the file compiles OK
class Class2 {
Struct1!Class1 subscribers;
}
void main() {}
Re: Exceptions on Windows being "swallowed"
Not sure if related to OP's issue, but quite often on Windows I get mystery crashes with no stack trace, so I typically use WinDbg Preview (modern version of WinDbg) to locate the problem. Seems to work every time.
Re: Translating Java into D
Potentially relevant old thread: https://forum.dlang.org/thread/ssdcoqhylmskfytfi...@forum.dlang.org
Re: Input engine
On Monday, 16 September 2019 at 02:05:37 UTC, Joel wrote: I was using DSFML 2.1.1[0] for keyboard input, but with the ... Since you still want to use the library - have you looked upstream at the SFML project to see if they are having problems there? Might be worth trying to write a small C/C++ test program against it to see if the problem is there, or just with the D bindings. I've had the whole macOS crash, with trying to get Allegro working on it ... I hope you are filing bug reports! That's pretty serious and they'd probably want to know about it.
Re: Linking to -framework on MacOS
And depending on the version of macOS / which framework you're linking to, you might need to specify a search path as well (-F): lflags "-framework" "SomeFramework" "-framework" "AnotherFramework" "-F/Library/Frameworks" IIRC I didn't need that -F parameter on 10.9, but now I do with 10.14. But it's for my own frameworks, not system ones.
Re: problems with swig generated code
Do you know whether SWIG's D generator is even being maintained? I've searched for it on the forums in the past and got the impression that it's outdated.
Re: Local static class fields
On Monday, 12 August 2019 at 22:48:43 UTC, Bert wrote: I have a recursive class structure(think of a graph or tree) and I need to keep a global state for it, If I'm understanding the problem correctly, it seems like you have a choice to make: either "bloat" the child nodes by the size of a pointer/reference to the shared tree state (4 or 8 bytes), or forego that by traversing the tree (from child to root node) every time you want to access the state. But if you don't want traversal every time, you're going to have to cache some kind of pointer (or Tree ID in the case of a central dictionary). I suppose if you got down to the nitty-gritty maybe you could use an 8- or 16-bit value for the key ID? (Disclosure: I know absolutely zero about how D lays out classes and structs in memory, this might not save any memory at all) It would help if you could provide some rough metrics: - How deep you expect each recursive structure to be (from root to deepest leaf node) - How many total nodes you expect to have across all trees (such that adding a single pointer to each instance would be memory-prohibitive) - How often each node will have to access the shared state (such that traversal-every-time would be too slow) That might help in figuring out the best approach.
Re: Desktop app with vibe.d
On Monday, 12 August 2019 at 10:41:57 UTC, GreatSam4sure wrote: I will be happy if I can build an app in D with fanciful ui. I will also be happy if you know any other way to build a fanciful ui in D like adobe flex, javafx, etc. I haven't seen anybody doing it yet, but in theory you could launch a browser / Electron instance / etc, and have it connect via gRPC to code written in D. Then you could have a fancy React UI and use D to do the heavy lifting.
Re: filtering a row of a jagged array
Thank you both! Ugh, I have to roll my eyes at missing such a simple error. (This literally occurred in the context of a bunch of other code using 'map' and 'reduce' with the exclamation point, so I don't know why my brain turned off for 'filter') Thanks again!
filtering a row of a jagged array
int[][] whatever = [ [0], [0, 1, 2], [5, 6, 7, 8, 9, 10] ]; writeln(whatever[2]);// [5, 6, 7, 8, 9, 10] writeln(typeid(whatever[2]));// int[] auto x = whatever[2].filter(x => x > 7); // error Error: template std.algorithm.iteration.filter cannot deduce function from argument types !()(int[], void), candidates are: ... Online example: https://run.dlang.io/is/LUXFuF ... I'm guessing I need to give the compiler some help understanding that this is an array of ints, but 1) how, and 2) why? [if typeid() seems to understand just fine?]
Re: LNK4255 warning - should I be concerned?
On Saturday, 10 August 2019 at 13:08:39 UTC, Dukc wrote: Let me guess, you're linking Vibe.D? I get those errors all the time while using it. Haven't noticed effect on behaviour but it might be related to why it won't compile as 32-bit. No, this is mostly with own code with I believe just one dependency (automem). Seems to work in both x86_mscoff and x86_64 (aside from the warning). But yeah, when googling this warning, all I found was people talking about it in the context of Vibe.D.
Re: LNK4255 warning - should I be concerned?
(Maybe I should add: this is on DMD 2.086.0, Windows 10)
LNK4255 warning - should I be concerned?
"warning LNK4255: library contain multiple objects of the same name; linking object as if no debug info" Is there some way to get more detail about this warning? Might help to know which objects ... My program is working fine now, but is this going to cause problems later on? Like when I want to debug?
Re: dll
For somebody who isn't familiar - what's the issue exactly?
Re: a way of approximating "API internal" visibility?
On Saturday, 18 May 2019 at 07:37:16 UTC, Laurent Tréguier wrote: Maybe what you need is `package(a.b.c)`? Ah, that's exactly what I needed! Thank you.
a way of approximating "API internal" visibility?
I'm working on a library spread across multiple modules/packages. Sometimes I have symbols that I would like to share between internal packages, but I don't want to make 'public' because then it would be exposed to the client-facing API. To a degree this could be gotten around by making things public internally, and then selectively 'public import'-ing individual symbols in the topmost client-facing module (vs. entire packages, as I'm doing now). However I have the following situation for which that won't work: I have a class that's going to be visible to the client, but inside that class I have methods that should only be accessible to other internal packages. So neither 'public' nor 'package' is what I want. I already collapsed one level of what I was doing to get around this issue (putting things in a common package even though I would have preferred they be in separate, sibling packages), but I'm not sure I could do that again without making a mess. Is there some way of approximating an access specifier between 'package' and 'public'? Or am I likely just structuring things very badly to begin with, to even have this problem? I'm not much of a C++ guy but I'd probably resort to using 'friend' to get around this, at least in the case of classes.
Re: local dub dependencies - relative paths, copyFiles, etc
Update: using the $PACKAGE_DIR environment variable for relative paths solved both issues.
local dub dependencies - relative paths, copyFiles, etc
First issue: I have a dub project (executable) that's dependent on another local dub project (library). It's cross-platform but I'm having this problem in Windows at the moment... My D library links against a win32 DLL/LIB, and I'm specifying that in the dub.sdl for the library, relative to the library root / dub.sdl location. Sensible, no? However, when building the executable - in another location, referring to the library via a relative local path, I'm forced to modify the location of the win32 .LIB specification to be relative to my executable dub file, *not* the library. So it seems like dub forgets to calculate the path relative to the library, where the path is specified in the first place. Is this expected behavior? Is there some kind of special relative root I need to use in the library's dub.sdl? Second issue (perhaps related?) I'm specifying a copyFiles in the library project to gather up all the requisite .DLLs, which I would hope would be copied to my executable's target path ... but that doesn't appear to be working. The "copying files..." step shows up in the dub output, but no matter how I specify it (relative to library or executable or just gibberish), it appears nothing is happening during that step.
Re: Multitasking question: Making a picture viewer, loading lots of images in the background
I'm no threading expert but 1000 - if those indeed are real threads (like, preemptive OS threads) - is wa too many. My understanding is that there's no benefit to creating more than the number of hyperthreads your CPU supports (minus your main thread?). So you'd want a work queue of all the available work/images, and then some reasonable number of threads (4-12 depending on core count / hyperthreading) taking work as they need it from that queue. You should probably be looking at std.parallelism (TaskPool etc) for this. Perhaps somebody can provide a more detailed how-to ...
Re: DMD: can't get extern __gshared to work right (vs. LDC)
In the meantime, while I'm waiting for this bug to be noticed by
anybody with the skills to address it, what would be the most
elegant way of working around it?
Obviously I could do a:
version(Windows) {
export extern __gshared ...
} else {
extern __gshared ...
}
But what's the minimal way of toggling the presence of "export"
in a declaration? Using mixins feels kind of gross for this, but
if that's the only option ...
Almost makes me long for the C preprocessor :P
Re: Why -I flag does not work?
On Saturday, 9 February 2019 at 08:15:36 UTC, Victor Porton wrote:
Why does -I flag in DFLAGS does not work? (Ubuntu Linux)
Try adding the -i flag as well ("include imported modules in the
compilation"), or setting both importPaths and sourcePaths in
dub.json.
I'm not certain that will help, but long ago I was having similar
trouble and it was because I was importing, but not compiling, a
certain file.
For reference: https://dub.pm/package-format-json
Re: Handling big FP numbers
On Saturday, 9 February 2019 at 04:32:44 UTC, Murilo wrote: Thank you very much for clearing this up. But how do I make D behave just like C? Is there a way to do that? Off the top of my head, you'd have to link against libc so you could use printf() directly. But may I ask why that is so important to you?
Re: Handling big FP numbers
On Saturday, 9 February 2019 at 03:33:13 UTC, Murilo wrote:
Thanks but here is the situation, I use printf("%.20f", 0.1);
in both C and D, C returns 0.1555 whereas D
returns 0.10001000. So I understand your point, D
rounds off more, but that causes loss of precision, isn't that
something bad if you are working with math and physics for
example?
0.1 in floating point is actually 0.10001490116119384765625
behind the scenes.
So why is it important that it displays as:
0.1555
versus
0.10001000
?
*Technically* the D version has less error, relative to the
internal binary representation. Since there's no exact way of
representing 0.1 in floating point, the computer has no way of
knowing you really mean "0.1 decimal". If the accuracy is that
important to you, you'll probably have to look into software-only
number representations, for arbitrary decimal precision (I've not
explored them in D, but other languages have things like
"BigDecimal" data types)
Re: Handling big FP numbers
On Saturday, 9 February 2019 at 03:03:41 UTC, H. S. Teoh wrote: It's not only because of converting decimal to binary, it's also because double only has 64 bits to store information, and your number has far more digits than can possibly fit into 64 bits. Adding to that, here's a nice little online calculator that will show the binary representation of a given decimal number: https://www.h-schmidt.net/FloatConverter/IEEE754.html
Re: DMD: can't get extern __gshared to work right (vs. LDC)
On Friday, 8 February 2019 at 09:19:12 UTC, rikki cattermole wrote: File, inconsistent behavior is inconsistent. Not good. done: https://issues.dlang.org/show_bug.cgi?id=19660
Re: DMD: can't get extern __gshared to work right (vs. LDC)
On Friday, 8 February 2019 at 07:52:26 UTC, Kagamin wrote: AFAIK, export attribute doesn't do much on posix platforms. I created a minimal example and it definitely segfaults at runtime in the presence of "export" (on Mac, haven't tested linux). So it's required for Windows and silently evil for Mac... Any reason I shouldn't file a DMD bug for this?
Re: DMD: can't get extern __gshared to work right (vs. LDC)
Follow-up: The problem on DMD macOS is the "export" keyword. It ended up in my code during a similar-ish problem last year, when I was having trouble linking against DLL global variables on Windows. If I remove the "export" keyword in the D interface, it will work on macOS but break on Windows. (To reiterate: WITHOUT "export" on Windows, it refuses to link. WITH "export" on Mac, it seems to link but with incorrect results) Is this correct behavior?
DMD: can't get extern __gshared to work right (vs. LDC)
macOS 12, DMD 2.084.0 / LDC 1.14.0-beta1
I have a C API that exports some global variables, declared like
so:
.h file:
=
extern "C" {
#define PUBLIC_API __attribute__((visibility("default")))
struct __opaqueHandle; typedef __opaqueHandle* opaqueHandle_t;
PUBLIC_API extern const opaqueHandle_t kSomeGlobalValue;
}
.cpp file:
==
const opaqueHandle_t kSomeGlobalValue = (opaqueHandle_t)
kSomeInternalPointer;
.d file:
extern (C):
export extern __gshared opaqueHandle_t kSomeGlobalValue;
I have no issues linking against the resulting .dylib with a
C/C++ program, nor issues with DMD on Windows with the same code.
However with DMD on macOS, the value is coming through
incorrectly. It looks like a valid pointer value (vs. pure
garbage), but it's still incorrect. LDC2 works fine, no issues.
Is there some extra flag I need to pass to DMD on Mac to get it
to see this global properly? It links fine, no errors, but the
value is still wrong. I should also mention that this dylib
exports functions, too, and they are working fine even with DMD.
It's just the globals I'm having problems with.
Re: Easiest way to display images
On Thursday, 7 February 2019 at 00:10:50 UTC, Murilo wrote: "information harvesting" I mean Facebook as a whole, not your group specifically. FB is in the business of selling to advertisers, and the users are the product.
Re: Easiest way to display images
On Wednesday, 6 February 2019 at 01:04:43 UTC, Murilo wrote: You should later joing the facebook group Programming in D. The D community is small enough that it's unlikely anybody in that Facebook group, isn't already using the newsgroups / IRC / etc to discuss D. Even the official subreddit barely gets any traffic. What I'm trying to say is, you're not going to have much luck getting that Facebook group off the ground. FB adds nothing to the existing options, and worse it's just an elaborate scheme to harvest personal information which one can safely assume the vast majority of D programmers are privacy-savvy enough to avoid.
Re: crashing with no stack trace, why?
On Friday, 1 February 2019 at 09:00:32 UTC, JN wrote: For Windows, you can try VisualD and VSCode with C++ debugger. I tried both of those but neither seemed to work out of the gate. I didn't take notes but my vague memory is that VisualD wasn't picking up some local dub dependecies and/or something to do with 32-bit COFF linkage, and VSCode seemed to be trying to debug but it wouldn't show me a stack trace of my own code, just telling me it didn't have symbols for some Windows kernel DLL. I definitely need to sit down with one or both of those to understand how to get them to work in the future, because I lost way too much time to such a small issue!
Re: crashing with no stack trace, why?
On Thursday, 31 January 2019 at 11:28:40 UTC, bauss wrote: Did you compile it with debug info? Eg. -g Yep, I use dub for builds which does that by default. Until this bug I was getting the usual stack traces with my project since the beginning.
crashing with no stack trace, why?
I have a program that was crashing due to a "Conversion positive overflow", specifically calling .to!int on a too-large unsigned value. However it was simply crashing with an exit code (-1073740771 / 0xC41D), and I was having a heck of a time trying to debug on Windows. (Shoutout to the revamped WinDbg Preview, couldn't get anything else to work!) I wondered if there was something in my code that was causing the silent crash, so I isolated the calculation (with a little bit of context to mimic the in-situ code), but in a standalone .d file, I simply get the overflow exception with a normal stack trace. Is this something I should try to whittle down with DustMite to get to the bottom of, for a bug report? Or is there something I'm failing to understand about this kind of crash? This is on Windows 10 64-bit, DMD v2.084.0, both x86_mscoff and x86_64.
Re: struggling to link against a C global in D (win/vs2017)
On Monday, 29 October 2018 at 01:03:32 UTC, kinke wrote: export extern(C) extern __gshared int myIntValue; Bingo!! That did the trick. Thank you so much.
Re: struggling to link against a C global in D (win/vs2017)
On Monday, 29 October 2018 at 00:16:38 UTC, Stanislav Blinov wrote: Should it be extern(Windows), perchance?.. (I haven't D on Windows for ages). The stdcall calling convention? I think that would only matter for the function, and indeed, trying that breaks the function being able to link** (and the variable remains broken) ** in 32-bit mscoff mode - no effect on 64-bit (where I think stdcall isn't applicable)
Re: struggling to link against a C global in D (win/vs2017)
On Monday, 29 October 2018 at 00:04:54 UTC, Adam D. Ruppe wrote: Both are listed as extern, where is the actual variable stored? If it is in the dll, it shouldn't be extern there. It's defined in the .cpp file. This is how the built-in DLL template generates it - "extern" in the .h file, actual definition in the .cpp file. If you don't have "extern" there, anybody who #includes that .h file would inadvertently have the variable defined, which would result in duplicates (and won't compile).
struggling to link against a C global in D (win/vs2017)
So I have a DLL+LIB exporting this:
extern "C" {
extern DLLPROJECT_API int myIntValue;
DLLPROJECT_API int myIntFunc(int a, int b);
}
In my D app I'm declaring it this way:
extern (C) {
extern __gshared int myIntValue;
int myIntFunc (int a, int b);
}
The function seems to link OK, but the C global will not.
Combinations I've tried:
- dmd 32-bit, linked against a coffimplib'ed lib file. This links
both successfully BUT myIntValue is trashed. myIntFunc does work
properly however.
- dmd m32mscoff, linking against native VS2017 lib. Complains
about variable but not the function.
- dmd m64, linking against native VS2017 lib. Complains about the
variable but not the function.
- ldc2 64-bit, linking against native VS2017 lib. Complains about
the variable but not the function.
I've examined the .DLL directly and the exported name
"myIntValue" looks exactly like what dmd/ldc2 are complaining
they cannot find.
What's the magic recipe here to get this variable linked (and not
gibberish)?
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 08:38:56 UTC, Nicholas Wilson wrote: Oh yeah, I didn't think to mention that you need to compile them for them to fix your missing symbols problem. Wait, wut? Do modules that get pulled in from dub's "importPaths" not get compiled in the same way? The dstep-generated files were working for the most part -- standalone C functions had no problem -- it was only those structs that I was having problems with. But now that they're in the default /source folder, I don't get the linker errors anymore.
Re: link errors when using extern (C) structs
For the benefit of anybody who encounters a problem like this in the future ... originally I had my C library "header" files (renamed from .di to .d after the feedback from Nicholas) in a special 'headers/' subdir, used as an import path in dub.json. I simply moved those files to the source folder and everything started magically working. And thanks again, Nicholas!
Re: link errors when using extern (C) structs
On Sunday, 28 October 2018 at 03:39:41 UTC, Nicholas Wilson wrote:
write struct Foo {
double bar = 0.0; // The bitpattern of 0.0 is 0
}
Thank you for your response.
Can you elaborate on 'write struct...'? Is that special syntax? I
assumed so, but dmd doesn't like it. I also checked to see if you
meant "(manually re-write it as...)", but updating the struct
definition in the generated .d header with field values doesn't
seem to solve the __initZ issue, either. And redefining it in the
client .d module just shadows the header definition, so ...
link errors when using extern (C) structs
I'm wrapping a C library which has a lot of structs defined, and
I keep running into issues where dmd complains that .init isn't
defined ("Symbol Undefined __xxx__initZ" etc).
I'm struggling to narrow it down to a simple example that
demonstrates it - I actually made something that's kind of
minimal, but it goes from working to breaking depending on
whether the file extension is .di or .d, for the file containing
the extern (C)'ed struct definitions. Also it seems to depend (in
the .di case) on whether the C structs use double vs. int values
for their fields. (int fields work with either file extension)
But simply changing the file extension in my real project, of the
header files translated by dstep, seems to have no effect.
In short, it seems that for certain C structs I cannot use them
as a field in a D struct even with a manually-specified default
value - I get link errors no matter what (init/toHash/opEquals).
How can I get around that?
Am I supposed to be doing something with C structs to avoid these
kinds of errors in my D code? I've searched the forum but nothing
really jumps out at me as relevant.
Re: Caesar Cipher
Here's a newbie-friendly solution: https://run.dlang.io/is/4hi7wH
Re: How to test a DUB-based library during development?
On Wednesday, 31 January 2018 at 04:57:14 UTC, Joel wrote: When I try 'dub test' I get errors like 'Source file '/Users/joelchristensen/jpro/dpro2/JMiscLib/source/jmisc/base.d' not found in any import path.' You might want to ask this in a new thread so more people see it.
Re: How to proceed with learning to code Windows desktop applications?
On Wednesday, 31 January 2018 at 12:25:36 UTC, John Chapman wrote: Just to say that it is actually possible to write modern Windows apps in D - I've done it. WinRT is just COM. Granted it's not as easy as using Microsoft's language projections, but it's doable if you really want to. The .winmd files describing the WinRT API surface are machine-readable, so in theory some enterprising D developer should be able to generate an elegant D projection. But as with many things, there might not be much overlap between "those who can" and "those who want to" :P It's certainly beyond my skill level at the moment ...
Re: Don't expect class destructors to be called at all by the GC
On Wednesday, 31 January 2018 at 10:34:53 UTC, Mike Parker wrote: delete is deprecated: https://dlang.org/deprecate.html#delete Ah, thanks! Actually double-thanks, because my progress through your book is what prompted me to search for threads about class destructors. The existence of .destroy answers my question (namely, "should I just use 'delete', or my own .dispose method, for deterministic resource freeing?")
Re: Don't expect class destructors to be called at all by the GC
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote: I ended up calling .destroy on the class instance explicitly just so the destructor would run at the right time, right before nulling the reference so that the GC would collect the memory. Pardon my probable ignorance (D newbie and all), but why wouldn't a 'delete' work for this? https://dlang.org/spec/expression.html#delete_expressions
Re: How to proceed with learning to code Windows desktop applications?
There are far too many options for Windows GUI programming, so we probably need a bit more information about any constraints that are important to you. For example: - do you specifically want something that works well with D? or are you open to other languages? - are you just wanting to learn desktop programming in general? (Like the concepts involved) Or do you have a specific thing you want to create? I would personally suggest Delphi to somebody who wants to write Windows desktop apps and learn about event-driven development, howeverrr the language (Object Pascal) is insufferably archaic compared to something like D. But it is definitely the cleanest, least-overwhelming method of writing native Win32 applications for somebody with no prior experience. Then there's all the modern Microsoft stuff (WPF/XAML/WinRT/etc), but you pretty much have to use either .NET or C++ for that.
Re: Web Browser
It looks like there are some unmaintained D bindings for sciter: https://github.com/sciter-sdk/Sciter-Dport
Re: Asio Bindings?
I'm a little late (1.5 years) to the ASIO discussion party, but I recently wrote something for myself that may be useful to others: https://github.com/dewf/DASIOClient I haven't published to DUB yet because 1) it's a pretty naive implementation and 2) I'm still very new to D, and 3) there's a built-in logging thing that will probably annoy everybody (which is why I need to spend more time with D, so I can learn The Right Way) It's "batteries included" (DLL+LIB files for Win32/64), so you don't have to compile the C library yourself. Note: it currently only really supports the ASIOSTInt32LSB sample type, because that's what all my test hardware uses; I have no idea if the other sample types are in common use with modern audio interfaces. But the C library also passes through ASIOSTFloat32LSB/ASIOSTFloat64LSB, so it would be very easy to modify the D wrapper to accommodate those, as well. If the included example program plays silence, then you'll probably need a new sample type :)
Re: How to test a DUB-based library during development?
Ah, thank you! I replaced: "libs-windows-x86-dmd" with: "sourceFiles-windows-x86-dmd" (and added a .lib suffix) and now everything works as expected. I see now that I was using "libs" improperly. It seems more for system-wide libraries / things in the library search path, not to be used for individual .lib files. Thanks again, you saved me many hours this morning :)
Re: How to test a DUB-based library during development?
Thank you very much, very helpful! I'm currently attempting the (A) suggestion, but find that dub isn't fixing up the relative path to one of the parent's prerequisite libraries. In the parent: "libs-windows-x86-dmd": ["./lib/32/dmd/SomeLibrary"] This causes a warning when building the nested example, because it's not adjusting the path: "Warning 2: File Not Found .\lib\32\dmd\SomeLibrary.lib" If I manually override "libs-windows-x86-dmd" in the example's dub.json, it links despite the error, but if possible I would like users of my library to not have to concern themselves with linkage issues.
How to test a DUB-based library during development?
I want to create a library and eventually publish it via the DUB registry. Is there a simple example that shows how to test the library during development, before publishing (ie, before being able to add it as a dependency to another project)? I guess I'm just asking, what's the convention here? Do I create a separate project and then add my not-yet-published library via 'dub add-local'? Put everything in a unittest in the library itself? etc etc.
Re: htod (8.52.5n) not recognizing wchar_t?
Thanks!
htod (8.52.5n) not recognizing wchar_t?
According to this page (https://dlang.org/htod.html), wchar_t should be recognized as wchar. But I'm just getting an error: "Error: ')' expected" ... anywhere a wchar_t appears in my .h file. Anything I need to do? I'd prefer to keep this entire file uncommented so I don't always have to hand-edit the results of htod. cheers
