On Saturday, 10 February 2018 at 02:24:58 UTC, rikki cattermole
wrote:
On 09/02/2018 8:34 PM, Benjamin Thaut wrote:
-import switch makes me a little concerned, what exactly is it
changing that makes it required?
Thank you Rikki for derailing this topic with the first post. As
you might
My work on dll support for D continues. There is another
iteration I need help testing with.
Getting started tutorial:
http://stuff.benjamin-thaut.de/D/getting_started.html
The DIP can again found be here:
https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md
The DIP is not up to
On Thursday, 8 February 2018 at 21:09:33 UTC, JN wrote:
Hi,
is there any way to debug binaries on Windows? I'd at least
like to know which line of code made it crash. If it's D code,
I get a call trace usually, but if it's a call to a C library,
I get a crash and that's it. I am using VSCode
Am 27.01.2018 um 08:40 schrieb Walter Bright:
This clearly should be in bugzilla.
https://issues.dlang.org/show_bug.cgi?id=18324
--
Kind Regards
Benjamin Thaut
On Saturday, 27 January 2018 at 07:40:16 UTC, Walter Bright wrote:
This clearly should be in bugzilla.
As phobos or dmd bug?
Am 25.01.2018 um 19:42 schrieb Jonathan M Davis:
That particular switch statement is in a function that's deprecated and
scheduled to be completely removed in about six months, so I don't see much
point in worrying about it unless it's causing serious problems, and while
that symbol name is
Am 12.01.2018 um 04:02 schrieb Domain:
On Thursday, 11 January 2018 at 18:56:23 UTC, Benjamin Thaut wrote:
Am 11.01.2018 um 05:10 schrieb Domain:
[...]
So I cannot use phobos as a static library when I use dll?
If you have a single D-dll that is used from a C program then you can
use
Am 11.01.2018 um 05:10 schrieb Domain:
I restart my computer, and it can produce dll now. But when I compile exe:
dmd -m64 -useshared app.d -ofapp.exe
app.obj : error LNK2019: 无法解析的外部符号
_D3std12experimental6logger4core17stdThreadLocalLogFNdNfZCQCeQCdQBsQBo6Logger，
该符号在函数
Am 10.01.2018 um 20:32 schrieb Anonymouse:
I don't have a reduced testcase yet. I figured I'd ask if it's something
known before making the effort.
Are you by any chance mixing debug and release builds? Or are the
-version specifiers different when compiling the various parts of your
Am 10.01.2018 um 13:39 schrieb Domain:
Sorry, my mistake. But I cannot use your binary:
D:\>dmd -m64 -shared dll.d -ofdll.dll
Error: unrecognized file extension dll
This works just fine for me. What is the output when you execute "dmd
--version"?
--
Kind Regards
Benjamin Thaut
Am 10.01.2018 um 05:18 schrieb Domain:
On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
I'm currently back on dll support and I'm applying finishing touches
to my dll support PR. Now I want to know if I missed any corner cases
and it would be great if a few more people gave
Am 09.01.2018 um 16:03 schrieb Andre Pany:
I am building a bridge between Delphi and D. At the moment the
executable is written in D and the Dll (Firemonkey UI) is written in
Delphi. But I think I want to enable also the other way around. The D
coding which is then located in the Dll should
Lets say I have a library and it contains the following module:
module a;
struct SomeStruct
{
string name;
}
struct SomeOtherStruct(T)
{
~this()
{
typeid(T).initializer;
}
}
struct ThirdStruct
{
SomeOtherStruct!SomeStruct m;
}
And now I have a second module:
module b;
import
Am 09.01.2018 um 12:02 schrieb MrSmith:
Is it possible to put common code in exe, and use that code from dlls?
Or anything can be exported only by dll?
You can only export from dlls. I don't know of any use case where
exporting from a executable would make sense. No, you can't put common
Am 09.01.2018 um 05:19 schrieb Dylan Graham:
It's pretty basic but I'm glad it works. I'll try doing something more
advanced.
Hi Dylan,
I'm glad that it works for you. I'm curios though, why are you using an
import library for your plugin? Normally plugins are build without and
import
Am 08.01.2018 um 00:06 schrieb solidstate1991:
On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
I would volunteer, but I don't know how much I can do in my exam
session. Maybe in February, until then not much.
Just do some testing whenever you find time, keep monitoring
Am 07.01.2018 um 16:40 schrieb H3XT3CH:
I need it for windows and linux but primary for windows
On windows there is the MiniDumpWriteDump function:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680360(v=vs.85).aspx
This might sound misleading but besides being able to write
Am 07.01.2018 um 12:05 schrieb H3XT3CH:
Hello
i want to create a memory dump in D.
The memory dump is for forensic usage so it must a dump of the complete
ram.
Can anyone help me ?
I know that programms already exist that create correct dumps of my
memory but i want to understand how it works
Am 07.01.2018 um 00:42 schrieb Rubn:
Looks good. If you want testers though, providing binaries would be
beneficial. Compiling dmd/druntime/phobos on Windows can be a pain.
I made a binary distribution. I updated
http://stuff.benjamin-thaut.de/D/getting_started.html with the details.
--
Am 07.01.2018 um 15:08 schrieb MrSmith:
Does the implementation support dynamically loaded dlls?
Yes. There is even a test for it
--
Kind Regards
Benjamin Thaut
Am 07.01.2018 um 03:57 schrieb rikki cattermole:
> +infinity
>
> Few things I would like answered:
>
> - Why -useShared and not -fPIC?
>- If -useShared why not use it on *nix to turn on -fPIC?
Because the DIP says that -useshared and -fPIC are loosley comparable.
This does not mean that
I'm currently back on dll support and I'm applying finishing touches to
my dll support PR. Now I want to know if I missed any corner cases and
it would be great if a few more people gave the dll support a try.
-To try it out you will need to build dmd, druntime and phobos yourself.
I'm not
On Wednesday, 27 December 2017 at 20:04:29 UTC, Marc wrote:
I'd like to set the members of a class by its name at runtime,
I would do something like this:
__traits(getMember, myClass, name) = value;
but since name is only know at runtime, I can't use __traits().
What's a workaround for
On Wednesday, 27 December 2017 at 13:40:28 UTC, rumbu wrote:
Is that normal?
use std.math;
float f = float.max;
f += 1.0;
assert(IeeeFlags.overflow) //failure
assert(f == float.inf) //failure, f is in fact float.max
On the contrary, float.max + float.max will overflow. The
behavior is the
On Monday, 25 December 2017 at 16:35:26 UTC, realhet wrote:
Now I have my first DMD 64bit windows console app running. (And
I'm already afraid of the upcoming windowed application haha)
My recommendation for getting setup on Windows with D is as
follows:
1) Install the latest visual studio
On Thursday, 21 December 2017 at 13:30:32 UTC, David Nadlinger
wrote:
There would probably have to be some sort of compatibility flag
to avoid breaking all libraries on systems where symbols are
visible externally by default (Linux, ...).
— David
Agree, although this currently really is a
On Wednesday, 20 December 2017 at 10:15:45 UTC, Benjamin Thaut
wrote:
I found that both the make that comes with msys and the make
that comes with mingw work for me. I‘m currently on vacation
but once I‘m back and in case you are interrested I can post
the batch file I use to run the dmd
On Wednesday, 20 December 2017 at 08:09:53 UTC, Martin Nowak
wrote:
At some point `dub build` should get a `--shared` option to
change the meaning of `library` target types from
`staticLibrary` to `dynamicLibrary`. The shared libs could be
linked with absolute paths.
Would this work in all
On Monday, 18 December 2017 at 16:06:33 UTC, Jonathan Marler
wrote:
Trying to run the dmd test suite on windows, looks like Digital
Mars "make" doesn't work with the Makefile, I tried Gnu Make
3.81 but no luck with that either. Anyone know which version
of make it is supposed to work with on
On Tuesday, 24 October 2017 at 21:11:38 UTC, solidstate1991 wrote:
DIP45 has the solution (make export an attribute), it needs to
be updated for the new DIP format from what I heard. It needs
to be pushed, as Windows still the most popular OS on the
consumer side of things, then we can have
On Monday, 10 April 2017 at 18:56:42 UTC, BBasile wrote:
Hello, I have a trait for this:
https://github.com/BBasile/iz/blob/master/import/iz/types.d#L650
Hi BBasile,
I think your trait is a good starting point for my needs. Thanks.
In particular I want to know if the vtable of the class has the
class info member.
Is there any way to do this at compile time? At runtime?
Kind Regards
Benjamin Thaut
On Sunday, 26 March 2017 at 14:30:00 UTC, deadalnix wrote:
It's consistent. D's const is transitive, and D doesn't allow
you to specify const on the indirection of a reference type. So
there is no problem on the C++ mangling side of things, but,
arguably, there is one in D's sementic, that
Consider the following C++ and D source:
class Class
{
virtual ~Class(){}
};
// mangles as ?getClass@@YAPEAVClass@@XZ
Class * getClass() { return nullptr; }
// mangles as ?getClassConst@@YAPEBVClass@@XZ
const Class * getClassConst() { return nullptr; }
// mangles as
On Wednesday, 9 November 2016 at 16:34:13 UTC, Mario Silva wrote:
Hey everyone,
While compiling our 64-bit app under Windows, DMD is getting
out of memory.
I wasn't able to find a windows version of DMD64, is there even
one? If not, are there any plans? This is quite a show stopper
for us.
Please consider the following program:
import std.experimental.allocator.mallocator;
import std.experimental.allocator.building_blocks.allocator_list
: AllocatorList;
import std.experimental.allocator.building_blocks.free_list;
import std.experimental.allocator;
import std.stdio;
enum uint
On Saturday, 22 October 2016 at 07:12:48 UTC, Rainer Schuetze
wrote:
Please also consider that the main executable might not know
about DLLs being written in D. In that case all termination
must be triggered by the druntime DLL.
The case where the main executable is not D is working fine.
On Friday, 21 October 2016 at 19:40:52 UTC, Rainer Schuetze wrote:
The wrapper around main in the executable should work just as
any DLLs' DllMain, i.e. it should register/unregister its own
data segments with the GC and run its shared and TLS module
constructors/decoontructors. Everything
On Thursday, 20 October 2016 at 08:44:09 UTC, Ethan Watson wrote:
On Thursday, 20 October 2016 at 07:17:49 UTC, Benjamin Thaut
wrote:
Any suggestions how to solve this problem? Who are other
platforms doing it?
Would this also be a bigger problem if people use LoadLibrary
and don't
This is a topic really specific to druntime, I don't know a
better place to put it though.
rt_init increases the _initCount and rt_term decreases it and
only terminates the runtime in case the _initCount reaches zero
(see dmain2.d)
The problem now is as follows.
Each dynamic library that is
I would like to use std.paralellism.TaskPool to schedule various
tasks I create. The problem however is that these tasks don't
have a lifetime which is bound to any function scope I have. So I
need to create a new task object on the heap and push it into a
array for bookkeeping. The problem
Lets assume I have a allocator which cains together multiple
building blocks from std.experimental.allocator and at the end
there is a mallocator providing the underlying memory. Now I
alloacte a type which contains a pointer into GC memory.
Obviously the memory of the mallocator is not
On Saturday, 7 May 2016 at 06:08:01 UTC, Nicholas Wilson wrote:
In Dicebot's DConf talk he mentioned that it is possible to use
the top 16 bits for tagging pointers and the associated risks.
Regarding the GC not seeing a pointer if the top 16 bits are
used, whats to stop us from changing the
On Wednesday, 4 May 2016 at 17:53:32 UTC, cc wrote:
The OS is Win64 though the program is being compiled as 32-bit
and I'm using the 32-bit distributed DLL.
fmod.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS
Windows
Tried int and long as the return type, same issue both ways.
Tried
On Tuesday, 3 May 2016 at 19:06:30 UTC, cc wrote:
it fails to link with "Error 42: Symbol Undefined
_FMOD_System_CreateSound@20". With extern(C) it compiles and
runs but the problem from above persists.
Is this on Windows x64? Try replacing FMOD_RESULT by int. When
declaring the fmod
On Wednesday, 4 May 2016 at 06:37:28 UTC, Nordlöw wrote:
On Tuesday, 3 May 2016 at 12:31:10 UTC, Benjamin Thaut wrote:
I assume this is on windows? Yes its a known issue (I know
No, the problem occurs on my Linux aswell.
From core.runtime:
static this()
{
// NOTE: Some module ctors
On Tuesday, 3 May 2016 at 11:32:31 UTC, cc wrote:
Hello, I've been encountering a strange problem that seems to
occur after calling some external C functions. I've been
working on a program that incorporates the FMOD C API for
playing sound, with a simple D binding based off the C headers,
On Tuesday, 3 May 2016 at 10:52:20 UTC, Nordlöw wrote:
On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote:
AFAICT, stacktraces are not emitted with debug information when
Should be static shared module constructors.
errors occur in static module constructors. Is this a know bug?
My
Hi,
I'm wondering if it would be a good idea to put up my slides
before the talk. And when. On the day of the talk? Today?
Tomorrow (Start of the Conference)?
I assume if you wanted to do this you would simply do a PR to the
dconf.org site on GitHub?
Kind Regards
Benjamin Thaut
On Tuesday, 26 April 2016 at 08:42:21 UTC, Vadim Lopatin wrote:
Demo of DlangUI Scene3D engine - Minecraft-like voxel rendering
- is available for Android/ARM.
Post screenshots please.
On Monday, 25 April 2016 at 09:16:11 UTC, Iain Buclaw wrote:
Germany is a cash-in-hand country. Credit cards are rejected
in most places that I've tried.
Yes, I highly recommend having cash on you. Also ensure that its
not the big bank notes (e.g. 50€ 100€) most ticket machines only
take
On Wednesday, 20 April 2016 at 20:10:56 UTC, qznc wrote:
On Wednesday, 20 April 2016 at 07:53:53 UTC, Benjamin Thaut
wrote:
Is there a official presentation template for Dconf 2016? If
not it would be great if someone could create one. Many
programmers (me included) are not good with picking
Is there a official presentation template for Dconf 2016? If not
it would be greate if someone could create one. Many programmers
(me included) are not good with picking colors and thus
presentations usually don't look as good as they could.
Kind Regards
Benjamin Thaut
On Tuesday, 29 March 2016 at 23:41:28 UTC, Thalamus wrote:
dmd dllmain.d dll.def -w -wi -g
-map -ofLogic.dll -m64
-debug -shared
Anyone know what I should try next? Am I missing something
simple? :)
thanks!
Thalamus
You should be using "-gc" instead of "-g" when building 64-bit D
On Thursday, 25 February 2016 at 17:46:18 UTC, Thalamus wrote:
On Thursday, 25 February 2016 at 16:05:37 UTC, Benjamin Thaut
wrote:
[...]
Thanks Benjamin. When I went to whittle this down to its barest
essentials, though, the repro is pretty simple. It involves
LIBs, but not Dlls, and it
On Thursday, 25 February 2016 at 14:42:14 UTC, Thalamus wrote:
your entry point.
Hi Guillaume,
Thanks for responding so quickly! I had found that wiki page
before and I'd been following the "DLLs with a C Interface"
section closely. I had forgotten to add -shared when building
the DLL, but
On Saturday, 13 February 2016 at 12:44:40 UTC, Tofu Ninja wrote:
Is the TypeInfo given by typeid() guaranteed to be the same for
a type regardless of where I call it? I guess my question is,
is the TypeInfo a valid way to dynamically check types?
I am implementing a message passing system for
On Monday, 1 February 2016 at 02:56:06 UTC, Tofu Ninja wrote:
Just out of curiosity, does anyone have an octree
implementation for D laying around? Just looking to save some
time.
https://github.com/Ingrater/thBase/blob/master/src/thBase/container/octree.d
Its a loose octree implementation.
On Friday, 29 January 2016 at 13:38:20 UTC, Tomer Filiba wrote:
I can change all such invocations into ``func(FooPtr(null))``
but it's tedious and basically requires me to compile tens of
times before I'd cover everything. Is there some workaround to
make null implicitly convertible to my
On Thursday, 28 January 2016 at 18:33:19 UTC, Nordlöw wrote:
Thanks, I'm aware of these tools.
But it's easier to use the stacktrace...if I only get one. The
function where the assert() is called is, in turn, called in
hundreds of places.
Which platform are you on? Are all your binaries
On Tuesday, 26 January 2016 at 16:13:55 UTC, Manu wrote:
Probably, but the layout of the vtable is defined by the
interface,
and the interface type is always known, so I don't see why there
should be any problem. Whether it's extern(C++) or extern(D),
the
class populating the vtable with
On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote:
Now, D can do the exact same as C++ .
That is a lie. Large parts of druntime still allocate GC memory
and thus will cause the GC to run. For example core.thread. We
need a solution where druntime can be used without druntime
On Monday, 25 January 2016 at 19:45:21 UTC, Igor wrote:
Am I off target here?
Dlls are currently not properly supported in D, I would strongly
advice against using them. Just link everything statically and be
happy for now.
Kind Regards
Benjamin Thaut
On Monday, 25 January 2016 at 03:05:36 UTC, Daniel Murphy wrote:
On 25/01/2016 2:55 AM, Benjamin Thaut wrote:
I tried using a commit which was
the same date as the cdmd -> ddmd switch but that didn't work.
That's the only way I know to do it, it should work.
It seems that I was just a few
I'm currently merging a pretty large change over the C++->D
boundary within Dmd. This change includes many changes to
druntime and phobos. So I need the last revision of druntime and
phobos that still compile with cdmd exactly before the switch was
made. Unfortunately there is no git tag for
On Saturday, 23 January 2016 at 00:38:45 UTC, Dibyendu Majumdar
wrote:
On Friday, 22 January 2016 at 22:06:35 UTC, Dibyendu Majumdar
wrote:
Hi
I am trying to create a simple shared library that exports a D
function, but when I try to link to it I get errors such as:
error LNK2001:
On Tuesday, 12 January 2016 at 19:00:26 UTC, Andre wrote:
Hi,
I am not sure, whether this is a current limitation of the
windows dll functionality of D
or I am doing s.th. which will not work.
I have developed in D a windows DLL which creates class
instances by passing the name (using
Am 11.01.2016 um 18:27 schrieb Robert M. Münch:
Import symbols are symbols used for dll linking and start with "__imp_"
Is this a DMD convention or a general one? Never heard about this.
This seems to be a general convetion on windows. All c++ compilers I've
seen on windows so far emit
On Sunday, 10 January 2016 at 22:22:03 UTC, Robert M. Münch wrote:
I made to compile a bunch of libs on Win64 and got my D project
compiled as well. Only problem left are some strange unresolved
externals.
Linking...
dmd
Am 09.01.2016 um 16:45 schrieb Thalamus:
Hi Benjamin,
I wouldn't say I need DLLs to work fully _really_ badly. The only
non-negligible issue with single very large binaries that's crossed my
mind is patching, but we're years away from having to worry about that
too much. That being said, I'm
On Thursday, 7 January 2016 at 19:29:43 UTC, Thalamus wrote:
Hi everyone,
First off, I've been working with D for a couple of weeks now
and I think it's the bee's knees! :) Except for DLLs.
thanks! :)
Dlls don't currently work on Windows. The only thing that works
is giving your dlls a
On Friday, 1 January 2016 at 13:57:01 UTC, Rainer Schuetze wrote:
Please note that building with -lib puts every
function/declaration into it's own object file inside the
library, and unused class declarations are no longer in the
linked executable.
Ok, that is very good information. I
On Monday, 4 January 2016 at 15:02:05 UTC, Manu wrote:
Yeah, I've used this process before. Last time I reported a
raft of
LDC bugs I spent a few days doing this... but it's very
laborious, and
I don't have time to do it. I'm doing this work on borrowed
time as it
is.
Did you try dustmite?
On Wednesday, 30 December 2015 at 09:43:32 UTC, Rainer Schuetze
wrote:
I noticed something similar recently when compiling a C file
with /Gy, see
https://github.com/D-Programming-Language/druntime/pull/1446#issuecomment-160880021
The compiler puts all functions into COMDATs, but they are
My current work on the D compiler lead me to the following test
case which I put through a unmodified version of dmd 2.069.2
import core.stdc.stdio;
struct UnusedStruct
{
int i = 3;
float f = 4.0f;
};
class UnusedClass
{
int i = 2;
float f = 5.0f;
};
void
On Friday, 6 November 2015 at 16:21:35 UTC, Suliman wrote:
On Friday, 6 November 2015 at 13:50:56 UTC, Kagamin wrote:
MSVCR is a C runtime. On Linux it will depend on a C runtime
too.
But which part of my App depend on C runtime?
All of it. Phobos and druntime use the C runtime, that means
On Tuesday, 13 October 2015 at 07:17:20 UTC, Jonathan M Davis
wrote:
Ultimately, I think that we're better off with TDPL's
definition of synchronized classes than the synchronized
functions that we have now, so I do think that the change
should be made. However, I also think that
On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote:
I agree that synchronized classes / functions that not that
useful.
But synchronized statements, to me, make the intention of
locking explicit.
Synchronized statements are fine and serve a good purpose, no
need to delete them
On Saturday, 3 October 2015 at 14:47:02 UTC, Nachtraaf wrote:
I'm trying to create some linear algebra functions using simd
intrinsics. I watched the dconf 2013 presentation by Manu Evans
but i'm still confused about some aspects and the following
piece of code doesn't work. I'm trying to copy
On Tuesday, 8 September 2015 at 12:56:00 UTC, Laeeth Isharc wrote:
This is really very clear and helpful, and I appreciate your
taking the time. I will place it on the wiki if that's okay.
Thats ok.
Library support is surely one of the largest impediments to the
adoption of D, and we
On Monday, 7 September 2015 at 19:30:44 UTC, drug wrote:
07.09.2015 21:37, Benjamin Thaut пишет:
snip
So far I haven't found a situation where I couldn't make it
work the way
I wanted. Its just some work to write the D headers for the
C++ classes
and vise versa, because you have to
On Friday, 4 September 2015 at 16:19:49 UTC, Laeeth Isharc wrote:
Hi Benjamin
Would you be able to give a little more colour on what the
limits are of interoperability for C++ with DMD master or
release ? As I understand it destructors and constructors
don't work, and obviously it will get
On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner wrote:
Hi,
what is the current status of:
- Win x86/32bit/coff32 interop with C++?
- improvements for general C++ interop that were suppose to
come with 2.068
If you use either the -m64 or -mscoff32 interop should be pretty
good.
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote:
What about 32bit phobos? Last time I checked (2.067) only x64
was distributed.
You have to compile it yourself. Use the win64 makefile and
replace the arch=64 with
arch=32mscoff.
For more details see here:
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner
wrote:
What about 32bit phobos? Last time I checked (2.067) only x64
was distributed.
You have to
On Sunday, 30 August 2015 at 14:08:15 UTC, Dicebot wrote:
Follow-up to old
http://forum.dlang.org/thread/m9lhc3$1r1v$1...@digitalmars.com
thread by Benjamin
Short reminder of the issue:
Currently unsolved issue with finishing `export` implementation
is lack of convenient semantics for its
On Sunday, 30 August 2015 at 14:08:15 UTC, Dicebot wrote:
Follow-up to old
http://forum.dlang.org/thread/m9lhc3$1r1v$1...@digitalmars.com
thread by Benjamin
Oh, don't get me wrong. Its great that you also think about this
problem. Currently you seem to be the only other person here on
the
As a occasional contributor to dmd I usually manage to get
everything working the way I want by digging through the dmd
source code long enough, but sometimes bad / non-existing
documentation and missing knowdelge result in suboptimal
solutions or unsolved problems. I would greatly appreciate
On Saturday, 22 August 2015 at 20:22:58 UTC, David Nadlinger
wrote:
On Saturday, 22 August 2015 at 20:14:59 UTC, Walter Bright
wrote:
I'm not sure how export would help on Linux.
One of the use cases for export on Linux would be to set the
ELF visibility based on it. Emitting all the symbols
On Saturday, 22 August 2015 at 09:44:48 UTC, Martin Nowak wrote:
The export seems to be an arbitrary rule (and export is really
broken currently).
Let's just use every class that is linked into the binary (e.g.
weakly referencing them), then it'll naturally work with all
linker
On Sunday, 23 August 2015 at 13:09:46 UTC, Benjamin Thaut wrote:
The good news is, once I'm done with my windows DLL work the
code can be trivialy reused to make export control the
visibility of symbols on linux as well.
Kind Regards
Benjamin Thaut
But then you have the same problem on
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it.
On Friday, 21 August 2015 at 08:49:37 UTC, Jacob Carlborg wrote:
How is it limiting? That it only works with default
constructors? I don't think that underlying ClassInfo.find is
limiting, which is where the interesting part happens. I'm
pretty sure that Object.factory could be extended to
On Wednesday, 19 August 2015 at 14:45:31 UTC, Steven
Schveighoffer wrote:
In the case where the pointer changes, you are in trouble. The
original memory is now free, which means it can be overwritten
by something else (either the C heap or some other thread that
reallocates it). Then if your
On Tuesday, 18 August 2015 at 10:27:14 UTC, Casper Færgemand
wrote:
On Monday, 17 August 2015 at 19:38:21 UTC, Steven Schveighoffer
wrote:
// if the GC kicks in here we're f*
GC.addRange(mem, 512);
Can't you GC.disable around this whole thing?
GC.collect can still be called from another
On Monday, 17 August 2015 at 20:33:45 UTC, welkam wrote:
I might be wrong, but he should worry about GC before he
removes that memory range from GC managed list not after. And
his code smells to me. He gives full memory control to GC, but
then wants to take it away, fiddle and give it back. I
On Monday, 17 August 2015 at 19:38:21 UTC, Steven Schveighoffer
wrote:
On 8/17/15 3:27 PM, Benjamin Thaut wrote:
Consider the following code
void* mem = malloc(500);
GC.addRange(mem, 500);
mem = realloc(mem, 512); // assume the pointer didn't change
GC.removeRange(mem);
This is actually
Consider the following code
void* mem = malloc(500);
GC.addRange(mem, 500);
mem = realloc(mem, 512); // assume the pointer didn't change
GC.removeRange(mem);
// if the GC kicks in here we're f*
GC.addRange(mem, 512);
I digged into GC.addRange to find out if I simply can skip the
call to
On Monday, 10 August 2015 at 05:23:20 UTC, Walter Bright wrote:
On 8/9/2015 9:26 PM, Tofu Ninja wrote:
On Sunday, 9 August 2015 at 20:51:32 UTC, Walter Bright wrote:
On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:
On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d
I agree, and
1 - 100 of 253 matches
Mail list logo
