On Friday, 16 May 2014 at 16:58:38 UTC, Rainer Schuetze wrote:
On 14.05.2014 12:56, Marc Schütz schue...@gmx.net wrote:
On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
class C { C next; }
shared(C) list;
C newC()
{
return new C; // allocated on the local heap?
Yes,
Rainer Schuetze r.sagita...@gmx.de writes:
On 14.05.2014 12:56, Marc Schütz schue...@gmx.net wrote:
On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
class C { C next; }
shared(C) list;
C newC()
{
return new C; // allocated on the local heap?
Yes, because it doesn't
On 14.05.2014 12:56, Marc Schütz schue...@gmx.net wrote:
On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
class C { C next; }
shared(C) list;
C newC()
{
return new C; // allocated on the local heap?
Yes, because it doesn't say new shared(C).
}
void prependToList(C c)
On 14/05/14 23:47, Dmitry Olshansky wrote:
This is curious:
http://burntsushi.net/rustdoc/regex/
It seems they have compile time regular expressions too.
--
/Jacob Carlborg
On Thursday, 15 May 2014 at 06:30:40 UTC, Jacob Carlborg wrote:
On 14/05/14 23:47, Dmitry Olshansky wrote:
This is curious:
http://burntsushi.net/rustdoc/regex/
It seems they have compile time regular expressions too.
Yeah looks like my knowledge about their macro system is very
outdated.
On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote:
On 13.05.2014 13:09, Marc Schütz schue...@gmx.net wrote:
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
On 12.05.2014 13:53, Marc Schütz schue...@gmx.net wrote:
I'm surprised that you didn't include:
3.
Walter Bright:
On 5/12/2014 10:25 AM, bearophile wrote:
Walter Bright:
Unions of pointers are so rare in actual code that treating
them
conservatively is not a big problem.
std.variant.Algebraic is based on on std.variant.VariantN, and
on
std.variant.VariantN is based on an union, and
On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote:
On 05/13/2014 09:07 PM, Jacob Carlborg wrote:
On 2014-05-13 15:56, Dicebot wrote:
Judging by
http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you have been
proposing,
more like
On Tuesday, 13 May 2014 at 19:56:20 UTC, Rainer Schuetze wrote:
I just read the first chapters, and according to that, existing
local gcs needs write barriers, so we are back to my second
proposal. The implementation in the paper even adds read
barriers.
At this point, I suspect write
On 05/14/2014 06:41 PM, Wyatt wrote:
To me, shared is a type modifier that doesn't implicitely convert to
anything else without casting.
Interesting, maybe this should be clarified better. Having skimmed back
over chapter 13 of TDPL, my understanding of its semantics are that it
only really
14-May-2014 17:16, Dicebot пишет:
On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote:
On 05/13/2014 09:07 PM, Jacob Carlborg wrote:
On 2014-05-13 15:56, Dicebot wrote:
Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you
On 12.05.2014 13:53, Marc Schütz schue...@gmx.net wrote:
I'm surprised that you didn't include:
3. Thread-local GC, isolated zones (restricting where references to
objects of a particular heap can be placed), exempting certain threads
from GC completely, ...
This comes up from time to
On 13.05.2014 00:15, Martin Nowak wrote:
On 05/11/2014 08:18 PM, Rainer Schuetze wrote:
1. Use a scheme that takes a snapshot of the heap, stack and registers
at the moment of collection and do the actual collection in another
thread/process while the application can continue to run. This is
On Tuesday, 13 May 2014 at 06:12:46 UTC, Rainer Schuetze wrote:
On 13.05.2014 00:15, Martin Nowak wrote:
There is a problem with this scheme, copy-on-write is extremely
expensive when a mutation happens. That's one page fault
(context
switch) + copying a whole page + mapping the new page.
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
On 12.05.2014 13:53, Marc Schütz schue...@gmx.net wrote:
I'm surprised that you didn't include:
3. Thread-local GC, isolated zones (restricting where
references to
objects of a particular heap can be placed), exempting certain
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
This comes up from time to time, but to me it is very blurry
how this can work in reality.
The paper I linked on Friday [0] presents a collector like this.
Are there concerns I've missed that make that not applicable?
On Monday, 12 May 2014 at 19:32:49 UTC, Jacob Carlborg wrote:
On 2014-05-12 19:14, Dicebot wrote:
It lacks any good static reflection though. And this stuff is
damn
addictive when you try it of D caliber.
It has macros, that basically requires great support for static
reflection to be
On Tue, 13 May 2014 02:12:44 -0400, Rainer Schuetze r.sagita...@gmx.de
wrote:
On 13.05.2014 00:15, Martin Nowak wrote:
On 05/11/2014 08:18 PM, Rainer Schuetze wrote:
1. Use a scheme that takes a snapshot of the heap, stack and registers
at the moment of collection and do the actual
On 05/13/2014 03:56 PM, Dicebot wrote:
On Monday, 12 May 2014 at 19:32:49 UTC, Jacob Carlborg wrote:
On 2014-05-12 19:14, Dicebot wrote:
It lacks any good static reflection though. And this stuff is damn
addictive when you try it of D caliber.
It has macros, that basically requires great
On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer
wrote:
I know this is coming from a position of extreme ignorance, but
why do we have to do copy on write? What about pause on write?
Not sure how that will help? Pointers may still escape collection?
(but you get that with
On Tuesday, 13 May 2014 at 16:14:07 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer
wrote:
Not sure how that will help? Pointers may still escape
collection?
(as in not being traced, leading to freeing live memory)
On Tue, 13 May 2014 12:14:06 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer wrote:
I know this is coming from a position of extreme ignorance, but why do
we have to do copy on write? What about pause on
On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy
yebbliesnos...@gmail.com wrote:
Steven Schveighoffer wrote in message
news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
If a thread is doing only reads, or is only touching non-Scanned
memory, it continues.
How long do threads
On Tue, 13 May 2014 13:37:05 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy
yebbliesnos...@gmail.com wrote:
Steven Schveighoffer wrote in message
news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
If a thread is doing only
Steven Schveighoffer wrote in message
news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
If a thread is doing only reads, or is only touching non-Scanned memory,
it continues.
How long do threads usually go without touching the stack?
On 2014-05-13 15:56, Dicebot wrote:
Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you have been proposing,
more like hygienic version of C macros.
Hmm, I haven't looked at Rust macros that much.
--
/Jacob Carlborg
On Tuesday, 13 May 2014 at 17:37:05 UTC, Steven Schveighoffer
wrote:
On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy
yebbliesnos...@gmail.com wrote:
Steven Schveighoffer wrote in message
news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local...
If a thread is doing only reads, or is only
On Tuesday, 13 May 2014 at 17:22:19 UTC, Steven Schveighoffer
wrote:
The idea I had was to make them pause-on-write. This means,
when the original process attempts to write to the page, it
gets a page-fault, which pauses the thread until the collector
is done with it. This causes the same
On 13.05.2014 13:09, Marc Schütz schue...@gmx.net wrote:
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
On 12.05.2014 13:53, Marc Schütz schue...@gmx.net wrote:
I'm surprised that you didn't include:
3. Thread-local GC, isolated zones (restricting where references to
On 13.05.2014 14:20, Wyatt wrote:
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
This comes up from time to time, but to me it is very blurry how this
can work in reality.
The paper I linked on Friday [0] presents a collector like this. Are
there concerns I've missed that
On 05/13/2014 09:07 PM, Jacob Carlborg wrote:
On 2014-05-13 15:56, Dicebot wrote:
Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you have been proposing,
more like hygienic version of C macros.
Hmm, I haven't looked at Rust
On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote:
On 05/13/2014 09:07 PM, Jacob Carlborg wrote:
On 2014-05-13 15:56, Dicebot wrote:
Judging by
http://static.rust-lang.org/doc/0.6/tutorial-macros.html
those are not full-blown AST macros like ones you have been
proposing,
more like
On 12 May 2014 10:50, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
They are using Rust to write a safe and performant web browser while
developing
the language.
Sure. But that browser hasn't been released yet. Consider that I've written
safe and performant code in D,
On 12.05.2014 06:57, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Sunday, 11 May 2014 at 20:45:08 UTC, Rainer Schuetze wrote:
On 11.05.2014 22:33, Walter Bright wrote:
The Boehm collector cannot move objects around, the D one can.
Oh it can? Really?
Yes. D, for
On Monday, 12 May 2014 at 00:44:54 UTC, Andrei Alexandrescu wrote:
On 5/11/14, 2:49 PM, ponce wrote:
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of @, it's mostly and ~.
Heck I
didn't find any @ while casually browsing the code. It's like
they are
On Monday, 12 May 2014 at 07:12:29 UTC, Manu via Digitalmars-d
wrote:
You haven't told me how I can use the GC (or whatever memory
management scheme, I really don't care) in the low frequency
code
(again, read: almost all code ever), and not have it interfere
with
the high frequency code.
On Monday, 12 May 2014 at 00:44:54 UTC, Andrei Alexandrescu wrote:
On 5/11/14, 2:49 PM, ponce wrote:
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of @, it's mostly and ~.
Heck I
didn't find any @ while casually browsing the code. It's like
they are
On 12 May 2014 17:24, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 12 May 2014 at 07:12:29 UTC, Manu via Digitalmars-d wrote:
You haven't told me how I can use the GC (or whatever memory
management scheme, I really don't care) in the low frequency code
(again, read:
On Monday, 12 May 2014 at 00:50:24 UTC, Walter Bright wrote:
On 5/11/2014 1:59 PM, Timon Gehr wrote:
Borrowed pointers are not even superficially similar to near*.
They are
compatible with everything else, because they can store data
that was borrowed
from anywhere else.
As long as those
On Monday, 12 May 2014 at 08:10:43 UTC, Tommi wrote:
Perhaps: [..]
Somewhat surprisingly to me, you can later on change the borrowed
pointer in the mutable static 'Test' to point at a mutable static
int:
struct Test {
n: 'static int
}
static old: int = 111;
static mut new: int = 222;
On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
What? You've never offered me a practical solution.
I have, you've just rejected them.
What do I do?
1. you can simply do C++ style memory management. shared_ptr, etc.
2. you can have the non-pausible code running in a thread that is
On 5/11/2014 10:57 PM, Marco Leise wrote:
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright newshou...@digitalmars.com:
As long as those pointers don't escape. Am I right in that one cannot store a
borrowed pointer into a global data structure?
Right, and that's the point and entirely
Walter Bright:
But I don't see how this could work in Rust.
Ask it to competent Rust developers/programmers.
Bye,
bearophile
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
What? You've never offered me a practical solution.
I have, you've just rejected them.
What do I do?
1. you can simply do C++ style memory management. shared_ptr,
etc.
2.
On Monday, 12 May 2014 at 09:05:39 UTC, John Colvin wrote:
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
The only solutions to the libraries problem that I can see here
require drastic separation of calls to said libraries from any
even vaguely time critical code. This is quite
On Monday, 12 May 2014 at 09:05:39 UTC, John Colvin wrote:
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
What? You've never offered me a practical solution.
I have, you've just rejected them.
What do I do?
1. you can
Am Sun, 11 May 2014 22:11:28 -0700
schrieb Walter Bright newshou...@digitalmars.com:
But I thought ARC cannot be designed without GC to resolve
cycles.
It can be, there are various schemes to deal with that, including don't
create
cycles. GC is just one of them.
Am Mon, 12 May 2014 01:54:58 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 5/11/2014 10:57 PM, Marco Leise wrote:
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright newshou...@digitalmars.com:
As long as those pointers don't escape. Am I right in that one cannot
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
I like this owner/unique, borrow thing.
@ is managed (currently reference counted)
~ is owner
is borrow
I like it too. But a few notes:
1) The managed pointer @T has been deprecated and you should use
the standard library types GcT
Am Mon, 12 May 2014 09:32:58 +
schrieb Paulo Pinto pj...@progtools.org:
On Monday, 12 May 2014 at 09:05:39 UTC, John Colvin wrote:
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
What? You've never offered me a practical
On Monday, 12 May 2014 at 10:51:33 UTC, Marco Leise wrote:
Time will tell if all well written D libraries will be @nogc
to move the question of allocations to the user.
If there was such a thing as weakly nogc then we would could
do this
//some library function
void foo(OR, IR)(OR o, IR i)
On 05/12/2014 02:50 AM, Walter Bright wrote:
On 5/11/2014 1:59 PM, Timon Gehr wrote:
On 05/11/2014 10:05 PM, Walter Bright wrote:
That's clearly an additional benefit of the borrowed pointer notion. But
have you examined generated Rust code for the cost of inc/dec? I
haven't, but I don't see
Timon Gehr:
(Probably more, actually, because it does not provide
precision-unfriendly constructs such as undiscriminated unions.)
I suggested to add an optional method named onGC to unions that
if present is called at run-time by the GC to know what's the
real type of stored data, to make
On Sunday, 11 May 2014 at 18:18:41 UTC, Rainer Schuetze wrote:
For a reasonable GC I currently see 2 possible directions:
1. Use a scheme that takes a snapshot of the heap, stack and
registers at the moment of collection and do the actual
collection in another thread/process while the
On 05/12/2014 10:54 AM, Walter Bright wrote:
On 5/11/2014 10:57 PM, Marco Leise wrote:
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright newshou...@digitalmars.com:
As long as those pointers don't escape. Am I right in that one cannot
store a
borrowed pointer into a global data
On Mon, 12 May 2014 03:39:12 -0400, Manu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 12 May 2014 17:24, Dicebot via Digitalmars-d
You will like Don's talk this year ;)
I'm super-disappointed I can't make it this year!
?!! http://dconf.org/2014/talks/evans.html
We were
On Sun, 11 May 2014 16:33:04 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/11/2014 2:48 AM, Benjamin Thaut wrote:
Mostly percise doesn't help. Its either fully percise or beeing stuck
with a
impercise mark sweep.
This is not correct. It helps because most of the false
On 12 May 2014 18:45, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
What? You've never offered me a practical solution.
I have, you've just rejected them.
What do I do?
1. you can simply do C++ style memory
Manu:
we are an industry in desperate need of salvation,
it's LONG overdue, and I want something that actually works
well for us, not a crappy set of compromises because the
language has a fundamental incompatibility with my industry :/
Perhaps the game industry has to start the creation of
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
2. you can have the non-pausible code running in a thread that
is not registered with the gc, so the gc won't pause it. This
requires that this thread not allocate gc memory, but it can
use gc memory allocated by other threads, as
On 5/12/2014 3:18 AM, Marco Leise wrote:
Your were arguing against Michel Fortin's proposal on the
surface, when your requirement cannot even be fulfilled
theoretically it seems.
Lots of people use ARC without a GC.
Which could mean that you don't like
the idea of replacing D's GC with an
On 5/12/2014 5:15 AM, Timon Gehr wrote:
On 05/12/2014 10:54 AM, Walter Bright wrote:
On 5/11/2014 10:57 PM, Marco Leise wrote:
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright newshou...@digitalmars.com:
As long as those pointers don't escape. Am I right in that one cannot
store a
On 13 May 2014 02:16, bearophile via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Manu:
we are an industry in desperate need of salvation,
it's LONG overdue, and I want something that actually works well for us,
not a crappy set of compromises because the
language has a fundamental
On 5/12/2014 2:12 AM, Dicebot wrote:
I think this is more of library writing culture problem than engineering
problem. High quality library shouldn't rely on any internal allocations at all,
deferring this decision to user code. Otherwise you will eventually have
problems, GC or not.
Consider
On Monday, 12 May 2014 at 16:16:06 UTC, bearophile wrote:
Perhaps the game industry has to start the creation of a
language designed for its needs, like the scientific people
have done (Julia), the browser ones (Rust), the Web ones have
done, etc. With lot of work in less than ten years you
On Monday, 12 May 2014 at 17:03:18 UTC, Walter Bright wrote:
On 5/12/2014 2:12 AM, Dicebot wrote:
I think this is more of library writing culture problem than
engineering
problem. High quality library shouldn't rely on any internal
allocations at all,
deferring this decision to user code.
On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d
wrote:
But D is *so close*... and I like it! _
I have to say that this discussion has certainly left me
somewhat
intrigued by Rust though.
I've never given it a fair go because I find the syntax so
distasteful
and deterring.
I
On 5/12/2014 4:35 AM, bearophile wrote:
I suggested to add an optional method named onGC to unions that if present is
called at run-time by the GC to know what's the real type of stored data, to
make tracing more precise.
Unions of pointers are so rare in actual code that treating them
Walter Bright:
Unions of pointers are so rare in actual code that treating
them conservatively is not a big problem.
std.variant.Algebraic is based on on std.variant.VariantN, and on
std.variant.VariantN is based on an union, and often you use
algebraic data types to represent trees and
On 13 May 2014 03:17, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/12/2014 4:35 AM, bearophile wrote:
I suggested to add an optional method named onGC to unions that if
present is
called at run-time by the GC to know what's the real type of stored data,
to
make
On 13 May 2014 03:14, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote:
But D is *so close*... and I like it! _
I have to say that this discussion has certainly left me somewhat
intrigued by Rust though.
I've
On 5/12/2014 10:31 AM, Manu via Digitalmars-d wrote:
I just searched through my code, and 7 out of 12 unions had pointers.
Relative number of objects with unions, not declarations with unions!
On 5/12/2014 10:07 AM, Dicebot wrote:
We have already had discussion where I did state that current @nogc
implementation is not robust enough and failed to explain the use case for
weaker @nogc clearly. Conclusion was that we should return to this topic after
Don's DConf talk ;)
Sure - next
On 5/12/2014 10:25 AM, bearophile wrote:
Walter Bright:
Unions of pointers are so rare in actual code that treating them
conservatively is not a big problem.
std.variant.Algebraic is based on on std.variant.VariantN, and on
std.variant.VariantN is based on an union, and often you use
Walter Bright:
BTW, the RTinfo can be used to discriminate unions.
I don't know if std.variant.VariantN is already using such
RTinfo. I don't know much about RTinfo.
Bye,
bearophile
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
It doesn't matter where the false pointers are. The largest issue with false
pointers is not how many false pointers there are. It only matters how large the
block is that it points at. The larger your blocks get, the more likely they
are pointed
On 13 May 2014 03:44, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/12/2014 10:31 AM, Manu via Digitalmars-d wrote:
I just searched through my code, and 7 out of 12 unions had pointers.
Relative number of objects with unions, not declarations with unions!
Ah, well
On Monday, 12 May 2014 at 16:03:28 UTC, Manu via Digitalmars-d
wrote:
How long is a collect liable to take in the event the GC
threads need
to collect? Am I likely to lose my service threads for 100s of
milliseconds at a time?
I'll think on it, but I don't think there's anything practically
On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote:
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
pointing at it is roughly 1/256. This problem is just about
eliminated with
64-bit pointers.
Not generally true. This presumes that the heap is not in the
lower region of the
On 5/12/14, 10:25 AM, bearophile wrote:
Walter Bright:
Unions of pointers are so rare in actual code that treating them
conservatively is not a big problem.
std.variant.Algebraic is based on on std.variant.VariantN, and on
std.variant.VariantN is based on an union, and often you use
12-May-2014 22:08, Andrei Alexandrescu пишет:
On 5/12/14, 10:25 AM, bearophile wrote:
A hook that nulls all freelist heads just as the collection process
starts would be helpful.
One word - weak pointers. Then head of freelist is weak and can be
collected at whim.
Andrei
--
Dmitry
On 5/12/14, 11:17 AM, Dmitry Olshansky wrote:
12-May-2014 22:08, Andrei Alexandrescu пишет:
On 5/12/14, 10:25 AM, bearophile wrote:
A hook that nulls all freelist heads just as the collection process
starts would be helpful.
One word - weak pointers. Then head of freelist is weak and can be
On 13 May 2014 04:07, Kapps via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 12 May 2014 at 16:03:28 UTC, Manu via Digitalmars-d
wrote:
How long is a collect liable to take in the event the GC threads need
to collect? Am I likely to lose my service threads for 100s of
On Monday, 12 May 2014 at 18:07:51 UTC, Kapps wrote:
Depending on how tunable the GC is, I feel like it should be
possible to get away with a GC even for soft real-time programs
like games.
Even if you manage to make it work for game clients you also
should make it work for low latency game
On 05/12/2014 06:37 PM, Walter Bright wrote:
On 5/12/2014 5:15 AM, Timon Gehr wrote:
On 05/12/2014 10:54 AM, Walter Bright wrote:
On 5/11/2014 10:57 PM, Marco Leise wrote:
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright newshou...@digitalmars.com:
As long as those pointers don't
On 2014-05-12 19:14, Dicebot wrote:
It lacks any good static reflection though. And this stuff is damn
addictive when you try it of D caliber.
It has macros, that basically requires great support for static
reflection to be usable.
--
/Jacob Carlborg
Andrei Alexandrescu:
I, too, felt the need of onGC() - actually preGC() - in my
allocators implementation.
...
A hook that nulls all freelist heads just as the collection
process starts would be helpful.
How is this going to help increase tracing precision of unions
(and Algebraic built on
On 5/12/14, 12:59 PM, bearophile wrote:
Andrei Alexandrescu:
I, too, felt the need of onGC() - actually preGC() - in my allocators
implementation.
...
A hook that nulls all freelist heads just as the collection process
starts would be helpful.
How is this going to help increase tracing
Andrei Alexandrescu:
How did I give the impression it has anything to do with
unions? -- Andrei
OK, so yours is not an answer to my proposal, nor related to it.
Bye,
bearophile
On 5/12/2014 12:36 PM, Timon Gehr wrote:
Do you mean the table is not actually global but passed by parameter,
Yes.
But note that the distinction between the two is often blurry. Under the hood on
some systems, global data is accessed via the equivalent of a hidden parameter.
On Mon, 12 May 2014 14:14:28 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote:
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
pointing at it is roughly 1/256. This problem is just about eliminated
with
Le 12/05/2014 19:14, Dicebot a écrit :
On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote:
But D is *so close*... and I like it! _
I have to say that this discussion has certainly left me somewhat
intrigued by Rust though.
I've never given it a fair go because I find the
On Mon, 12 May 2014 13:52:20 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
It doesn't matter where the false pointers are. The largest issue with
false
pointers is not how many false pointers there are. It only matters how
large
On Mon, 12 May 2014 17:32:09 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
The workaround is simply to keep it around, but that's not always a
scalable solution.
Sorry, actually you can free it. That's the correct workaround.
-Steve
On Monday, 12 May 2014 at 21:22:09 UTC, Steven Schveighoffer
wrote:
On Mon, 12 May 2014 14:14:28 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote:
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
pointing at it
On 05/11/2014 08:18 PM, Rainer Schuetze wrote:
1. Use a scheme that takes a snapshot of the heap, stack and registers
at the moment of collection and do the actual collection in another
thread/process while the application can continue to run. This is the
way Leandro Lucarellas concurrent GC
On Monday, 12 May 2014 at 19:13:50 UTC, Ola Fosheim Grøstad wrote:
On Monday, 12 May 2014 at 18:07:51 UTC, Kapps wrote:
Depending on how tunable the GC is, I feel like it should be
possible to get away with a GC even for soft real-time programs
like games.
Even if you manage to make it work
On 5/12/2014 2:32 PM, Steven Schveighoffer wrote:
It's still forbidden. Andrei wrote a template that will verify this at
runtime, but I don't recall its name.
Can you cite the spec where it says it's forbidden? Forgotten templates are not
a convincing argument.
Regardless, Java can use a
On Monday, 12 May 2014 at 22:27:06 UTC, Kapps wrote:
because it's so short. This is quite sufficient for most
projects, but perhaps could be tweaked a bit more for certain
aspects like gaming, possibly even enabling concurrent
collection
for generation 0/1, but I'm not sure if this works well
On 5/12/2014 2:28 PM, Xavier Bigand wrote:
All compile time things of D are marvelous.
This with the compile time and the language less error prone make me want D.
I am not sure I need safety so much. It's nice but not mandatory for any of my
projects. The only one which has to be safe is
1 - 100 of 419 matches
Mail list logo
