You can safely forget about RakNet by the looks.
"While I still get some inquiries, as of as of March 13, 2015 I've
decided to stop licensing so I can focus on changing the world through VR."
So based upon this, what would you like to do? Scratch or another
pre-existing protocol like
A fun project might be to use D's reflection to automatically
generate any C binding translators to a nice D interface and the
Ruby file to access it.
I did something similar back in the day for PHP and JavaScript...
it would be kinda tricky to do it with best efficiency, but
getting it to
On Saturday, 6 August 2016 at 01:44:04 UTC, Adam D. Ruppe wrote:
On Saturday, 6 August 2016 at 01:29:37 UTC, Mark "J" Twain
wrote:
Of course, exceptions have TraceInfo... could that be used
anywhere or hacked to get what I need?
The function is defaultTraceHandler in druntime for what the
On Saturday, 6 August 2016 at 01:29:37 UTC, Mark "J" Twain wrote:
Of course, exceptions have TraceInfo... could that be used
anywhere or hacked to get what I need?
The function is defaultTraceHandler in druntime for what the
exceptions do:
http://arsdnet.net/dcode/stacktrace.d
more text
Any solution out there that can get call stack, file and line
info? Similar to exceptions but I simply want to track memory
allocations and need the complete call stack rather than just the
previous call(using __FUNCTION__/__FILE__/etc), which is usually
useless.
Of course, exceptions have
On 08/05/2016 03:49 PM, H.Loom wrote:
On Friday, 5 August 2016 at 21:25:41 UTC, Ali Çehreli wrote:
malloc stores the allocation size and other information right before
the pointer that it returns.
TIL. Is it guaranteed for any malloc implementation ? I'm a bit surpised
to read that. I thought
On Friday, 5 August 2016 at 21:25:41 UTC, Ali Çehreli wrote:
malloc stores the allocation size and other information right
before the pointer that it returns.
TIL. Is it guaranteed for any malloc implementation ? I'm a bit
surpised to read that. I thought these kind of trick was only
used
On 08/05/2016 12:55 PM, Mark J Twain wrote:
I use malloc to allocate some memory, then free it later. For monitoring
purposes, I would like to know how much is free'ed by free by just
knowing the object. Or, rather, given a ptr allocated by malloc, bet the
block size it allocated from the ptr
On Friday, 5 August 2016 at 21:07:02 UTC, H.Loom wrote:
On Friday, 5 August 2016 at 20:54:59 UTC, Mark "J" Twain wrote:
On Friday, 5 August 2016 at 20:43:12 UTC, H.Loom wrote:
On Friday, 5 August 2016 at 19:55:22 UTC, Mark "J" Twain
wrote:
[...]
You can wrap the C memory allocations
On Friday, 5 August 2016 at 20:54:59 UTC, Mark "J" Twain wrote:
On Friday, 5 August 2016 at 20:43:12 UTC, H.Loom wrote:
On Friday, 5 August 2016 at 19:55:22 UTC, Mark "J" Twain wrote:
[...]
You can wrap the C memory allocations functions with a version
identifier, e.g
version(stat)
{
Hi,
I have some experience with c++, and am considering using either
D or python for a game.
1. It is going to be online-based, would D be a good choice for
writing both the client and server? I haven't seen any online
games using D yet.
2. A concern is interfacing with c++. I'll like to
On Friday, 5 August 2016 at 20:43:12 UTC, H.Loom wrote:
On Friday, 5 August 2016 at 19:55:22 UTC, Mark "J" Twain wrote:
[...]
You can wrap the C memory allocations functions with a version
identifier, e.g
version(stat)
{
__gshared size_t[size_t] sizes;
}
version(stat)
{
auto
On Friday, 5 August 2016 at 19:55:22 UTC, Mark "J" Twain wrote:
I use malloc to allocate some memory, then free it later. For
monitoring purposes, I would like to know how much is free'ed
by free by just knowing the object. Or, rather, given a ptr
allocated by malloc, bet the block size it
On Friday, 5 August 2016 at 19:21:38 UTC, Mark "J" Twain wrote:
On Friday, 5 August 2016 at 08:32:42 UTC, kink wrote:
On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain
[...]
This has absolutely nothing to do with D as these are C
functions, so you'd be better off asking this in
I use malloc to allocate some memory, then free it later. For
monitoring purposes, I would like to know how much is free'ed by
free by just knowing the object. Or, rather, given a ptr
allocated by malloc, bet the block size it allocated from the ptr
alone.
Some C compilers have special
On Friday, 5 August 2016 at 08:32:42 UTC, kink wrote:
On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain [...]
This has absolutely nothing to do with D as these are C
functions, so you'd be better off asking this in another forum.
Um, then I wonder why I am using D? Why does D even
On Friday, 5 August 2016 at 18:37:43 UTC, Jonathan M Davis wrote:
I know that dmd supports VS' binary format and linker for
64-bit (dmc and optlink were never updated to support 64-bit),
and I think that 32-bit support for using VS' library format
and linker were added later. So, I'm fairly
On Friday, 5 August 2016 at 18:28:48 UTC, ciechowoj wrote:
Is default dmd linker (on MS Windows, OPTILINK) supposed to
link against static libraries created with Visual Studio?
Specifically I want to link a project compiled on windows with
dmd against pre-compiled library `libclang.lib` from
On Friday, August 05, 2016 18:28:48 ciechowoj via Digitalmars-d-learn wrote:
> Is default dmd linker (on MS Windows, OPTILINK) supposed to link
> against static libraries created with Visual Studio?
>
> Specifically I want to link a project compiled on windows with
> dmd against pre-compiled
Is default dmd linker (on MS Windows, OPTILINK) supposed to link
against static libraries created with Visual Studio?
Specifically I want to link a project compiled on windows with
dmd against pre-compiled library `libclang.lib` from LLVM suite.
I'm pretty sure they used Visual Studio to
On 8/5/16 6:25 AM, Nordlöw wrote:
Should range members front() and back() assert() or throw() on emptyness?
If it should assert() doesn't that lead to unsafer code in release mode?
What's the consensus here?
If the code is @safe, then it should trigger an error if you try to do
unsafe
On Thursday, 4 August 2016 at 13:14:34 UTC, llaine wrote:
Here is my repo https://github.com/llaine/ruby-dlang
FYI: to!string is kinda slow. If you want to do a fast blank, you
should avoid conversions actually, I'm surprised it is faster
than the native Ruby one at all.
On Thursday, August 04, 2016 08:13:59 Alex via Digitalmars-d-learn wrote:
> What I think about is something like this:
> https://dpaste.dzfl.pl/d37cfb8e513d
Okay, you have
enum bool isKey(T) = is(typeof(T.init < T.init) : bool);
template isNullable(T) { enum isNullable = __traits(compiles,
On Friday, 5 August 2016 at 13:14:41 UTC, Kagamin wrote:
Bug 6585 is not fixed. Variant wasn't written for shared and
immutable types. As a workaround wrap the array in a class.
Thanks! It worked.
Though it's strange that
Variant wasn't written for shared and immutable types
because, for
Hi,
To view Cyrillic CMD on Windows can be used
`std.process.executeShell("chcp 65001 ");` and it works.
What should I use to change the encoding to UTF-8 to the compiler
messages in `pragma(msg, ...)` on Visual D?
//
import std.stdio, std.process;
void
On Friday, August 05, 2016 15:50:50 H.Loom via Digitalmars-d-learn wrote:
> On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
> > Should range members front() and back() assert() or throw() on
> > emptyness?
> >
> > If it should assert() doesn't that lead to unsafer code in
> > release
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
Should range members front() and back() assert() or throw() on
emptyness?
If it should assert() doesn't that lead to unsafer code in
release mode?
What's the consensus here?
nothing, but examples exist in pbobos such as front() on
Bug 6585 is not fixed. Variant wasn't written for shared and
immutable types. As a workaround wrap the array in a class.
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
If it should assert() doesn't that lead to unsafer code in
release mode?
What's the consensus here?
It is unsafer, the rationale is that your code should be debugged
to comply with the assumption of the release mode that there are
no
On Friday, August 05, 2016 10:25:42 Nordlöw via Digitalmars-d-learn wrote:
> Should range members front() and back() assert() or throw() on
> emptyness?
>
> If it should assert() doesn't that lead to unsafer code in
> release mode?
>
> What's the consensus here?
It is a programming error for any
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
Should range members front() and back() assert() or throw() on
emptyness?
If it should assert() doesn't that lead to unsafer code in
release mode?
What's the consensus here?
if you can and it is not costly, do `assert(false,
On 08/05/2016 12:25 PM, Nordlöw wrote:
Should range members front() and back() assert() or throw() on emptyness?
If it should assert() doesn't that lead to unsafer code in release mode?
What's the consensus here?
It's an error in the program when front/back is called on an empty
range.
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote:
Should range members front() and back() assert() or throw() on
emptyness?
I'm pretty sure it's assert() here. The contract is that the
caller is responsible for checking emptiness beforehand, and the
whole of Phobos is coded around
Should range members front() and back() assert() or throw() on
emptyness?
If it should assert() doesn't that lead to unsafer code in
release mode?
What's the consensus here?
On Thursday, 4 August 2016 at 21:03:52 UTC, Mark "J" Twain wrote:
How can I construct a va_list for vsprintf when all I have is
the a list of pointers to the data, without their type info?
A va_list seems to be a packed struct of values and/or pointers
to the data. While I could construct
On Thursday, 4 August 2016 at 23:35:55 UTC, bachmeier wrote:
On Thursday, 4 August 2016 at 17:11:04 UTC, Adam D. Ruppe wrote:
Happy that you guys put this on the Wiki !!
36 matches
Mail list logo
