On 30.05.2013 22:59, Benjamin Thaut wrote:
One possible complication: memory block operations would have to treat
pointer fields differently somehow.
Would they? Shouldn't it be possible to make this part of the post-blit
constructor?
Not in general, e.g. reference counting needs to know
On 2013-05-31 06:02:20 +, Rainer Schuetze r.sagita...@gmx.de said:
On 30.05.2013 22:59, Benjamin Thaut wrote:
One possible complication: memory block operations would have to treat
pointer fields differently somehow.
Would they? Shouldn't it be possible to make this part of the post-blit
On 31.05.2013 12:54, Michel Fortin wrote:
On 2013-05-31 06:02:20 +, Rainer Schuetze r.sagita...@gmx.de said:
On 30.05.2013 22:59, Benjamin Thaut wrote:
One possible complication: memory block operations would have to treat
pointer fields differently somehow.
Would they? Shouldn't it
On 05/24/2013 01:51 AM, Joseph Rushton Wakeling wrote:
Maybe someone else can point to an example, but I can't think of any language
prior to D that has both the precision and speed to be useful for games and
embedded programming, and that also has GC built in.
So it seems to me that this
On 29.05.2013 10:06, Manu wrote:
What do you think is easier, or perhaps even POSSIBLE in D?
A good RC approach, or a V8 quality concurrent+incremental GC?
I think none of them is feasible without write-barriers on pointer
modifications in heap memory. That means extra code needs to be
On 30 May 2013 19:50, Rainer Schuetze r.sagita...@gmx.de wrote:
On 29.05.2013 10:06, Manu wrote:
What do you think is easier, or perhaps even POSSIBLE in D?
A good RC approach, or a V8 quality concurrent+incremental GC?
I think none of them is feasible without write-barriers on pointer
On Thursday, 30 May 2013 at 11:17:08 UTC, Manu wrote:
His GC looked good, clearly works better for the sociomantic
guys, but I
can't imagine it, or anything like it, will ever work on
embedded platforms?
No hardware/OS support... is it possible to emulate the
requires features?
Well,
On 30 May 2013 21:20, Dicebot m.stras...@gmail.com wrote:
On Thursday, 30 May 2013 at 11:17:08 UTC, Manu wrote:
His GC looked good, clearly works better for the sociomantic guys, but I
can't imagine it, or anything like it, will ever work on embedded
platforms?
No hardware/OS support... is
On Thursday, 30 May 2013 at 11:31:53 UTC, Manu wrote:
Which 'both' cases?
OS support for fork+CoW vs no support, own implementation
On Thursday, 30 May 2013 at 11:34:20 UTC, Dicebot wrote:
On Thursday, 30 May 2013 at 11:31:53 UTC, Manu wrote:
Which 'both' cases?
OS support for fork+CoW vs no support, own implementation
If you can modify the DMD compiler to output a special sequence
of instructions whenever you assign
On 2013-05-30 12:04:09 +, Diggory digg...@googlemail.com said:
If you can modify the DMD compiler to output a special sequence of
instructions whenever you assign to a pointer type then you can do a
concurrent/incremental GC with minimal OS or hardware support.
This also happens to be
On 30.05.2013 13:16, Manu wrote:
On 30 May 2013 19:50, Rainer Schuetze r.sagita...@gmx.de
mailto:r.sagita...@gmx.de wrote:
On 29.05.2013 10:06, Manu wrote:
What do you think is easier, or perhaps even POSSIBLE in D?
A good RC approach, or a V8 quality
One possible complication: memory block operations would have to treat
pointer fields differently somehow.
Would they? Shouldn't it be possible to make this part of the post-blit
constructor?
Kind Regards
Benjamin Thaut
On Wednesday, 29 May 2013 at 00:40:16 UTC, Manu wrote:
On 29 May 2013 03:27, Paulo Pinto pj...@progtools.org wrote:
Am 28.05.2013 15:33, schrieb Steven Schveighoffer:
On Sat, 25 May 2013 01:52:10 -0400, Manu
turkey...@gmail.com wrote:
What does ObjC do? It seems to work okay on embedded
On Wednesday, 29 May 2013 at 00:46:18 UTC, Steven Schveighoffer
wrote:
On Tue, 28 May 2013 20:40:03 -0400, Manu turkey...@gmail.com
wrote:
ObjC and WinRT are both used successfully on embedded
hardware, I'm really
wondering if this is the way to go for embedded in D.
V8 uses an incremental
On 29.05.2013 02:46, Steven Schveighoffer wrote:
On Tue, 28 May 2013 20:40:03 -0400, Manu turkey...@gmail.com wrote:
ObjC and WinRT are both used successfully on embedded hardware, I'm
really
wondering if this is the way to go for embedded in D.
V8 uses an incremental collector (somehow?),
On Wednesday, 29 May 2013 at 07:18:49 UTC, Rainer Schuetze wrote:
On 29.05.2013 02:46, Steven Schveighoffer wrote:
On Tue, 28 May 2013 20:40:03 -0400, Manu turkey...@gmail.com
wrote:
ObjC and WinRT are both used successfully on embedded
hardware, I'm
really
wondering if this is the way
On 29 May 2013 17:18, Rainer Schuetze r.sagita...@gmx.de wrote:
On 29.05.2013 02:46, Steven Schveighoffer wrote:
On Tue, 28 May 2013 20:40:03 -0400, Manu turkey...@gmail.com wrote:
ObjC and WinRT are both used successfully on embedded hardware, I'm
really
wondering if this is the way
On 2013-05-29 09:05, Paulo Pinto wrote:
The main reason was that the GC never worked properly given the C
underpinnings of Objective-C.
Too many libraries failed to work properly with GC enabled, plus you
needed to fill your code with GC friendly annotations.
So I imagine Apple tried to find
On 2013-05-29 08:06:15 +, Manu turkey...@gmail.com said:
What do you think is easier, or perhaps even POSSIBLE in D?
A good RC approach, or a V8 quality concurrent+incremental GC?
I get the feeling either would be acceptable, but I still kinda like idea
of the determinism an RC collector
On 2013-05-29 09:46:20 +, Jacob Carlborg d...@me.com said:
On 2013-05-29 09:05, Paulo Pinto wrote:
The main reason was that the GC never worked properly given the C
underpinnings of Objective-C.
Too many libraries failed to work properly with GC enabled, plus you
needed to fill your code
On Sat, 25 May 2013 01:52:10 -0400, Manu turkey...@gmail.com wrote:
What does ObjC do? It seems to work okay on embedded hardware (although
not
particularly memory-constrained hardware).
Didn't ObjC recently reject GC in favour of refcounting?
Having used ObjC for the last year or so
On Tuesday, 28 May 2013 at 13:33:39 UTC, Steven Schveighoffer
wrote:
I asked David Nadlinger at the conference whether we could
leverage this power in LDC, since LLVM is the compiler back-end
used by Apple, but he said all those optimization passes are in
the Objective-C front-end.
Hm,
On 28 May 2013 23:33, Steven Schveighoffer schvei...@yahoo.com wrote:
On Sat, 25 May 2013 01:52:10 -0400, Manu turkey...@gmail.com wrote:
What does ObjC do? It seems to work okay on embedded hardware (although
not
particularly memory-constrained hardware).
Didn't ObjC recently reject GC in
On Tue, 28 May 2013 09:50:42 -0400, David Nadlinger s...@klickverbot.at
wrote:
On Tuesday, 28 May 2013 at 13:33:39 UTC, Steven Schveighoffer wrote:
I asked David Nadlinger at the conference whether we could leverage
this power in LDC, since LLVM is the compiler back-end used by Apple,
but
On Tuesday, 28 May 2013 at 13:56:03 UTC, Manu wrote:
Yep, I can imagine it would work really well, if the front-end
implemented
the logic to factor out redundant inc/dec ref's.
It isn't the best idea to do this sort of optimizations
(entirely) in the front-end, because you really want to be
On 29 May 2013 00:01, David Nadlinger s...@klickverbot.at wrote:
On Tuesday, 28 May 2013 at 13:56:03 UTC, Manu wrote:
Yep, I can imagine it would work really well, if the front-end implemented
the logic to factor out redundant inc/dec ref's.
It isn't the best idea to do this sort of
Am 28.05.2013 15:33, schrieb Steven Schveighoffer:
On Sat, 25 May 2013 01:52:10 -0400, Manu turkey...@gmail.com wrote:
What does ObjC do? It seems to work okay on embedded hardware
(although not
particularly memory-constrained hardware).
Didn't ObjC recently reject GC in favour of refcounting?
On 29 May 2013 03:27, Paulo Pinto pj...@progtools.org wrote:
Am 28.05.2013 15:33, schrieb Steven Schveighoffer:
On Sat, 25 May 2013 01:52:10 -0400, Manu turkey...@gmail.com wrote:
What does ObjC do? It seems to work okay on embedded hardware
(although not
particularly memory-constrained
On Tue, 28 May 2013 20:40:03 -0400, Manu turkey...@gmail.com wrote:
ObjC and WinRT are both used successfully on embedded hardware, I'm
really
wondering if this is the way to go for embedded in D.
V8 uses an incremental collector (somehow?), which I've been saying is
basically mandatory for
Am 25.05.2013 07:52, schrieb Manu:
On 25 May 2013 15:29, deadalnix deadal...@gmail.com
mailto:deadal...@gmail.com wrote:
On Saturday, 25 May 2013 at 05:18:12 UTC, Manu wrote:
On 25 May 2013 15:00, deadalnix deadal...@gmail.com
mailto:deadal...@gmail.com wrote:
On Saturday, 25 May 2013 at 05:52:23 UTC, Manu wrote:
But it would be deterministic, and if the allocations are few,
the cost
should be negligible.
You'll pay a tax on pointer write, not on allocations ! It won't
be negligible !
They're still non-deterministic though. And unless (even
Am 25.05.2013 03:29, schrieb Manu:
On 25 May 2013 04:20, Benjamin Thaut c...@benjamin-thaut.de
mailto:c...@benjamin-thaut.de wrote:
[...]
See, I have spend a decade on core tech/engine code meticulously
worrying about memory allocation. I don't think a GC is an outright no-go.
But we certainly
Am 25.05.2013 03:29, schrieb Manu:
Win64 works for me out of the box... ?
For me dmd produces type names like modulename.typename.subtypename
which will causes internal errors within the visual studio debugger in
some cases. Also debugging of static / global variabels is not possible
On Saturday, 25 May 2013 at 05:29:31 UTC, deadalnix wrote:
This is technically possible, but you said you make few
allocations. So with the tax on pointer write or the reference
counting, you'll pay a lot to collect very few garbages. I'm
not sure the tradeoff is worthwhile.
Incidentally,
On 05/24/2013 04:33 PM, Manu wrote:
But anyway, after fixing the obvious Phobos offenders, another huge
step would be to get TempAlloc into druntime and used wherever
possible in Phobos.
How does that work?
One pattern I've used a lot is, since we have a regular 60hz timeslice
and
On 25 May 2013 21:03, Benjamin Thaut c...@benjamin-thaut.de wrote:
Am 25.05.2013 03:29, schrieb Manu:
Win64 works for me out of the box... ?
For me dmd produces type names like modulename.typename.**subtypename
which will causes internal errors within the visual studio debugger in some
On 5/25/13 6:28 PM, Manu wrote:
On 25 May 2013 21:03, Benjamin Thaut c...@benjamin-thaut.de
mailto:c...@benjamin-thaut.de wrote:
Am 25.05.2013 03:29, schrieb Manu:
Win64 works for me out of the box... ?
For me dmd produces type names like
On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
Johannes Pfau's work in progress -vgc command line option [3]
would be another great tool that would help people identify GC
allocations. This or something similar could also be used to
document throughout phobos when GC
On Friday, 24 May 2013 at 05:49:18 UTC, Sean Cavanaugh wrote:
Most general allocators choke on multi-threaded code, so a
large part of customizing allocations is to get rid lock
contention.
It is safe to assume that the future is multithreaded and that
general allocator won't choke on that
On Thursday, 23 May 2013 at 18:22:54 UTC, Joseph Rushton Wakeling
wrote:
On 05/23/2013 08:13 PM, Brad Anderson wrote:
Now I'm wondering what can be done to foster this newly
acquired credibility in
games. By far the biggest issue I hear about when it comes to
people working on
games in D is
On Friday, 24 May 2013 at 07:57:42 UTC, Don wrote:
It's worth noting that our code at Sociomantic faces *exactly*
the same issues.
It is worth noting that _anyone_ trying to write code with either
soft or hard real-time requirements faces exactly the same issues
;)
On 2013-05-24 01:51, Joseph Rushton Wakeling wrote:
This also seems to suggest that an ideal solution might be to have several
different GC strategies, the choice of which could be made at compile time
depending on what's most suitable for the application in question.
You can already swap the
On Friday, 24 May 2013 at 08:01:35 UTC, Jacob Carlborg wrote:
On 2013-05-24 01:51, Joseph Rushton Wakeling wrote:
This also seems to suggest that an ideal solution might be to
have several
different GC strategies, the choice of which could be made at
compile time
depending on what's most
On Friday, 24 May 2013 at 08:01:35 UTC, Jacob Carlborg wrote:
On 2013-05-24 01:51, Joseph Rushton Wakeling wrote:
This also seems to suggest that an ideal solution might be to
have several
different GC strategies, the choice of which could be made at
compile time
depending on what's most
24-May-2013 09:02, Manu пишет:
On 24 May 2013 14:11, Marco Leise marco.le...@gmx.de
mailto:marco.le...@gmx.de wrote:
Am Thu, 23 May 2013 20:21:47 -0400
schrieb Jonathan M Davis jmdavisp...@gmx.com
mailto:jmdavisp...@gmx.com:
At some point, we're probably going to need to
On Friday, 24 May 2013 at 09:40:03 UTC, Dmitry Olshansky wrote:
Alternatively just make a TLS buffer as scratchpad and use that
everywhere.
I believe that's what TempAlloc is for.
On 2013-05-23 23:42, Joseph Rushton Wakeling wrote:
I'm also in agreement with Manu. There may well already be bugs for some of
them -- e.g. there is one for toUpperInPlace which he referred to, and the
source of the allocation is clear and is even responsible for other bugs:
24-May-2013 13:49, Jacob Carlborg пишет:
On 2013-05-23 23:42, Joseph Rushton Wakeling wrote:
I'm also in agreement with Manu. There may well already be bugs for
some of
them -- e.g. there is one for toUpperInPlace which he referred to, and
the
source of the allocation is clear and is even
On Friday, 24 May 2013 at 09:49:40 UTC, Jacob Carlborg wrote:
toUpper/lower cannot be made in place if it should handle all
Unicode. Some characters will change their length when convert
to/from uppercase. Examples of these are the German double S
and some Turkish I.
In that case it should
On Fri, 24 May 2013 01:11:17 +0100, Manu turkey...@gmail.com wrote:
/agree, except the issue I raised, when ~ is used in phobos.
That means that function is now off-limits. And there's no way to know
which functions they are...
It's not the allocation caused by ~ which is the issue though is
On Friday, 24 May 2013 at 10:24:13 UTC, Regan Heath wrote:
It's not the allocation caused by ~ which is the issue though
is it, it's the collection it might trigger, right?
Depends. When it comes to real-time software you can't say
without studying specific task requirements. Stop-the-world
On Fri, 24 May 2013 11:38:40 +0100, Dicebot m.stras...@gmail.com wrote:
On Friday, 24 May 2013 at 10:24:13 UTC, Regan Heath wrote:
It's not the allocation caused by ~ which is the issue though is it,
it's the collection it might trigger, right?
Depends. When it comes to real-time software
On 2013-05-24 07:02, Manu wrote:
I don't think it's hack-ish at all, that's precisely what the stack is
there for. It would be awesome for people to use alloca in places that
it makes sense.
Especially in cases where the function is a leaf or leaf-stem (ie, if
there is no possibility of
On 2013-05-24 12:01, Peter Alexander wrote:
In that case it should only allocate when needed. Most strings are ASCII
and will not change size.
What I mean is that something called InPlace doesn't go hand in hand
with something that allocates. There's always std.ascii.
--
/Jacob Carlborg
On Friday, 24 May 2013 at 12:29:43 UTC, Jacob Carlborg wrote:
On 2013-05-24 12:01, Peter Alexander wrote:
In that case it should only allocate when needed. Most strings
are ASCII
and will not change size.
What I mean is that something called InPlace doesn't go hand
in hand with something
On 05/24/2013 11:49 AM, Jacob Carlborg wrote:
toUpper/lower cannot be made in place if it should handle all Unicode. Some
characters will change their length when convert to/from uppercase. Examples
of
these are the German double S and some Turkish I.
Surely it's possible to put in-place
On Friday, 24 May 2013 at 13:37:36 UTC, Joseph Rushton Wakeling
wrote:
(To be honest, feels a bit of a design flaw in Unicode that
character length can
change between lower- and uppercase.)
Unfortunately it's either that or lose compatibility with ASCII.
Lower case dotted-i needs to be one
On 24 May 2013 17:57, Don turnyourkidsintoc...@nospam.com wrote:
On Thursday, 23 May 2013 at 18:22:54 UTC, Joseph Rushton Wakeling wrote:
On 05/23/2013 08:13 PM, Brad Anderson wrote:
Now I'm wondering what can be done to foster this newly acquired
credibility in
games. By far the biggest
On 24 May 2013 18:01, Jacob Carlborg d...@me.com wrote:
On 2013-05-24 01:51, Joseph Rushton Wakeling wrote:
This also seems to suggest that an ideal solution might be to have several
different GC strategies, the choice of which could be made at compile time
depending on what's most suitable
On 24 May 2013 19:40, Dmitry Olshansky dmitry.o...@gmail.com wrote:
24-May-2013 09:02, Manu пишет:
On 24 May 2013 14:11, Marco Leise marco.le...@gmx.de
mailto:marco.le...@gmx.de wrote:
Am Thu, 23 May 2013 20:21:47 -0400
schrieb Jonathan M Davis jmdavisp...@gmx.com
On 24 May 2013 19:49, Jacob Carlborg d...@me.com wrote:
On 2013-05-23 23:42, Joseph Rushton Wakeling wrote:
I'm also in agreement with Manu. There may well already be bugs for some
of
them -- e.g. there is one for toUpperInPlace which he referred to, and the
source of the allocation is
On 24 May 2013 20:24, Regan Heath re...@netmail.co.nz wrote:
On Fri, 24 May 2013 01:11:17 +0100, Manu turkey...@gmail.com wrote:
/agree, except the issue I raised, when ~ is used in phobos.
That means that function is now off-limits. And there's no way to know
which functions they are...
On Fri, May 24, 2013 at 09:34:41AM +1000, Manu wrote:
[...]
Just to be clear, while I've hard many have, I've NEVER argued for
removing the GC. I think that's a hallmark of a modern language. I
want to use the GC in games, but it needs to have performance
characteristics that are applicable to
I might just add that there are some other important targets as well in the
vein of this discussion.
DLL's *still* don't work properly. druntime/phobos still don't really work
as dll's.
They are getting some attention, but it's been a really long standing and
seriously major issue. Shared
On 2013-05-24, 16:24, Peter Alexander wrote:
On Friday, 24 May 2013 at 13:37:36 UTC, Joseph Rushton Wakeling wrote:
(To be honest, feels a bit of a design flaw in Unicode that character
length can
change between lower- and uppercase.)
Unfortunately it's either that or lose compatibility
On 25 May 2013 00:58, H. S. Teoh hst...@quickfur.ath.cx wrote:
On Fri, May 24, 2013 at 09:34:41AM +1000, Manu wrote:
[...]
Just to be clear, while I've hard many have, I've NEVER argued for
removing the GC. I think that's a hallmark of a modern language. I
want to use the GC in games, but
24-May-2013 18:35, Manu пишет:
On 24 May 2013 19:40, Dmitry Olshansky dmitry.o...@gmail.com
mailto:dmitry.o...@gmail.com wrote:
24-May-2013 09:02, Manu пишет:
On 24 May 2013 14:11, Marco Leise marco.le...@gmx.de
mailto:marco.le...@gmx.de
mailto:marco.le...@gmx.de
24-May-2013 18:38, Manu пишет:
On 24 May 2013 19:49, Jacob Carlborg d...@me.com mailto:d...@me.com
wrote:
On 2013-05-23 23:42, Joseph Rushton Wakeling wrote:
I'm also in agreement with Manu. There may well already be bugs
for some of
them -- e.g. there is one for
On Fri, 24 May 2013 15:50:43 +0100, Manu turkey...@gmail.com wrote:
On 24 May 2013 20:24, Regan Heath re...@netmail.co.nz wrote:
It sounds kinda complex... but I'm not qualified to comment.
Yeah, there is complexity. It all boils down to whether it is possible
using modern GC techniques
On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:
Errr, well, 1ms is about 7% of the frame, that's quite a long
time.
I'd be feeling pretty uneasy about any library that claimed to
want 7% of
the whole game time, and didn't offer any visual/gameplay
benefits...
Maybe if the GC happened to
Am 23.05.2013 20:13, schrieb Brad Anderson:
While there hasn't been anything official, I think it's a safe bet to
say that D is being used for a major title, Remedy's Quantum Break,
featured prominently during the announcement of Xbox One. Quantum Break
doesn't come out until 2014 so the
Am 24.05.2013 17:02, schrieb Manu:
I might just add that there are some other important targets as well in
the vein of this discussion.
DLL's *still* don't work properly. druntime/phobos still don't really
work as dll's.
They are getting some attention, but it's been a really long standing
and
On Fri, May 24, 2013 at 07:55:44PM +0200, deadalnix wrote:
On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:
Errr, well, 1ms is about 7% of the frame, that's quite a long time.
I'd be feeling pretty uneasy about any library that claimed to want
7% of the whole game time, and didn't offer any
On Sat, 25 May 2013 01:16:47 +1000
Manu turkey...@gmail.com wrote:
Errr, well, 1ms is about 7% of the frame, that's quite a long time.
I'd be feeling pretty uneasy about any library that claimed to want
7% of the whole game time, and didn't offer any visual/gameplay
benefits... Maybe if the
On Saturday, May 25, 2013 00:33:10 Manu wrote:
Yeah, I've often wanted API's in that fashion too.
I wonder if it would be worth creating overloads of allocating functions
that receive an output buffer argument, rather than return an allocated
buffer...
Too messy?
We already have stuff like
On 05/23/2013 03:21 PM, H. S. Teoh wrote:
On Thu, May 23, 2013 at 10:15:50PM +0200, QAston wrote:
On Thursday, 23 May 2013 at 20:07:08 UTC, Steven Schveighoffer
wrote:
While I'm not specifically addressing the ability or not to
disable the GC (I agree D has problems tehre), deprecating the
On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
@nogc comes to mind (I believe Andrei mentioned it during one
of the talks released). [1][2]
I would love to have something like @nogc to guarantee there's no
hidden or misplaced allocations in a section of code or
optionally
On 25 May 2013 03:55, deadalnix deadal...@gmail.com wrote:
On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:
Errr, well, 1ms is about 7% of the frame, that's quite a long time.
I'd be feeling pretty uneasy about any library that claimed to want 7% of
the whole game time, and didn't offer
On 25 May 2013 04:20, Benjamin Thaut c...@benjamin-thaut.de wrote:
Am 23.05.2013 20:13, schrieb Brad Anderson:
While there hasn't been anything official, I think it's a safe bet to
say that D is being used for a major title, Remedy's Quantum Break,
featured prominently during the
On 25 May 2013 05:05, H. S. Teoh hst...@quickfur.ath.cx wrote:
On Fri, May 24, 2013 at 07:55:44PM +0200, deadalnix wrote:
On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:
One important detail to consider for realtime usage, is that it's
very unconventional to allocate at runtime at
On 25 May 2013 11:26, Manu turkey...@gmail.com wrote:
On 25 May 2013 03:55, deadalnix deadal...@gmail.com wrote:
With real time constraint, a memory overhead is better than a pause.
I wouldn't necessarily agree. Depends on the magnitude of each.
What sort of magnitude are we talking?
If
On Friday, 24 May 2013 at 19:44:23 UTC, Jonathan M Davis wrote:
We already have stuff like format vs formattedWrite where one
allocates and the
other takes an output range. We should adopt that practice in
general. Where
possible, it should probably be done with an overload of the
function,
On Saturday, 25 May 2013 at 02:41:00 UTC, Brad Anderson wrote:
On Friday, 24 May 2013 at 19:44:23 UTC, Jonathan M Davis wrote:
We already have stuff like format vs formattedWrite where one
allocates and the
other takes an output range. We should adopt that practice in
general. Where
possible,
On Saturday, May 25, 2013 04:40:58 Brad Anderson wrote:
On Friday, 24 May 2013 at 19:44:23 UTC, Jonathan M Davis wrote:
We already have stuff like format vs formattedWrite where one
allocates and the
other takes an output range. We should adopt that practice in
general. Where
possible,
On Saturday, 25 May 2013 at 01:26:19 UTC, Manu wrote:
Freeing is a no-realtime-cost operation, since memory
management is usually
scheduled for between-scenes, or passed to other threads.
And I've never heard of a major title that uses smart pointers,
and assigns
them around the place at
On Saturday, 25 May 2013 at 01:56:42 UTC, Manu wrote:
Understand, I have no virtual-memory manager, it won't page,
it's not a
performance problem, it will just crash if I mis-calculate this
value.
So the GC is kind of out.
On 25 May 2013 15:00, deadalnix deadal...@gmail.com wrote:
On Saturday, 25 May 2013 at 01:56:42 UTC, Manu wrote:
Understand, I have no virtual-memory manager, it won't page, it's not a
performance problem, it will just crash if I mis-calculate this value.
So the GC is kind of out.
Yeah,
On Saturday, 25 May 2013 at 05:18:12 UTC, Manu wrote:
On 25 May 2013 15:00, deadalnix deadal...@gmail.com wrote:
On Saturday, 25 May 2013 at 01:56:42 UTC, Manu wrote:
Understand, I have no virtual-memory manager, it won't page,
it's not a
performance problem, it will just crash if I
On 25 May 2013 15:29, deadalnix deadal...@gmail.com wrote:
On Saturday, 25 May 2013 at 05:18:12 UTC, Manu wrote:
On 25 May 2013 15:00, deadalnix deadal...@gmail.com wrote:
On Saturday, 25 May 2013 at 01:56:42 UTC, Manu wrote:
Understand, I have no virtual-memory manager, it won't page,
While there hasn't been anything official, I think it's a safe
bet to say that D is being used for a major title, Remedy's
Quantum Break, featured prominently during the announcement of
Xbox One. Quantum Break doesn't come out until 2014 so the
timeline seems about right (Remedy doesn't appear
On 05/23/2013 08:13 PM, Brad Anderson wrote:
Now I'm wondering what can be done to foster this newly acquired credibility
in
games. By far the biggest issue I hear about when it comes to people working
on
games in D is the garbage collector. You can work around the GC without too
much
On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
While there hasn't been anything official, I think it's a safe
bet to say that D is being used for a major title, Remedy's
Quantum Break, featured prominently during the announcement of
May I ask where this intel comes from? Do
On Thu, May 23, 2013 at 08:22:43PM +0200, Joseph Rushton Wakeling wrote:
On 05/23/2013 08:13 PM, Brad Anderson wrote:
Now I'm wondering what can be done to foster this newly acquired
credibility in games. By far the biggest issue I hear about when it
comes to people working on games in D
On Thursday, 23 May 2013 at 18:43:01 UTC, Szymon Gatner wrote:
On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
While there hasn't been anything official, I think it's a safe
bet to say that D is being used for a major title, Remedy's
Quantum Break, featured prominently during
On Thursday, 23 May 2013 at 18:22:54 UTC, Joseph Rushton Wakeling
wrote:
On 05/23/2013 08:13 PM, Brad Anderson wrote:
Now I'm wondering what can be done to foster this newly
acquired credibility in
games. By far the biggest issue I hear about when it comes to
people working on
games in D is
On Thursday, 23 May 2013 at 18:50:11 UTC, Brad Anderson wrote:
On Thursday, 23 May 2013 at 18:43:01 UTC, Szymon Gatner wrote:
On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
While there hasn't been anything official, I think it's a
safe bet to say that D is being used for a
On 2013-05-23 20:43, H. S. Teoh wrote:
On the other hand, perhaps functions that *need* to allocate should be
labelled as such (esp. in the Phobos docs), so that users know what
they're getting into.
Perhaps using a UDA.
--
/Jacob Carlborg
On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
While there hasn't been anything official, I think it's a safe
bet to say that D is being used for a major title, Remedy's
Quantum Break, featured prominently during the announcement of
Xbox One. Quantum Break doesn't come out
On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
While there hasn't been anything official, I think it's a safe
bet to say that D is being used for a major title, Remedy's
Quantum Break, featured prominently during the announcement of
Xbox One. Quantum Break doesn't come out
1 - 100 of 138 matches
Mail list logo
