"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 wan
(Maybe I should add: this is on DMD 2.086.0, Windows 10)
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
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
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!
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
la
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 po
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.
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.
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
Potentially relevant old thread:
https://forum.dlang.org/thread/ssdcoqhylmskfytfi...@forum.dlang.org
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.
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 - nei
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!
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.
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)
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 b
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
(libra
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
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 libr
Thank you.
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.
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
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
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 fol
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-gene
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
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, actua
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** (
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.
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
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.
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 so
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
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.
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 opaqueHandl
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 Windo
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
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
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 o
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,
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 im
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
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 wa
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 th
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
Update: using the $PACKAGE_DIR environment variable for relative
paths solved both issues.
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
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.
For somebody who isn't familiar - what's the issue exactly?
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
Thanks!
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 h
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 n
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
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
It looks like there are some unmaintained D bindings for sciter:
https://github.com/sciter-sdk/Sciter-Dport
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 lea
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
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 .destr
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 .winm
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.
Here's a newbie-friendly solution: https://run.dlang.io/is/4hi7wH
63 matches
Mail list logo