On Saturday, 31 May 2014 at 13:44:22 UTC, Manu via Digitalmars-d
wrote:
I would switch to a D fork in an instant if it satisfied my
requirements...
Maybe the best approach is to
1. Start with the basic requirements and acceptable restrictions
and shrink the semantics to fit them. Then use
.
The GC is very fast even if it needs to lookup this info but I
believe it wouldn't stay low-cpu in a 128 GB of RAM server with
3GB/s of memory traffic with a wide range of memory segment
sizes.
I think a decent proposal would be to
1- Introduce a new GC pointer type, e.g. a void' (its
On 29 May 2014 03:35, via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Wednesday, 28 May 2014 at 17:27:20 UTC, Dicebot wrote:
Adding GC pointer type does not enable anything that you can't do write
now for high-level applications and does not help at all low-level
applications. It is
Big language change which does not fix any fundamental issue. I
think at stage of language development it is better to not even
discuss those ;)
On Wednesday, 28 May 2014 at 14:16:56 UTC, Dicebot wrote:
Big language change which does not fix any fundamental issue.
Having a GC pointer type + several other mechanisms could reduce
the amount of scanned memory to a level where it slips below the
pain threshold for interactive apps.
On Wednesday, 28 May 2014 at 17:21:18 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 28 May 2014 at 14:16:56 UTC, Dicebot wrote:
Big language change which does not fix any fundamental issue.
Having a GC pointer type + several other mechanisms could
reduce the amount of scanned memory to a
On Tuesday, 27 May 2014 at 16:47:38 UTC, Etienne wrote:
You're right, it's obviously easier to keep it as the same
pointer syntax but hijack the stdlib malloc functions to
forcibly go through the GC.
If the GC controls everything, you can keep the info in 8 byte
pointers.
- The GC always
On Wednesday, 28 May 2014 at 17:35:18 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 28 May 2014 at 17:27:20 UTC, Dicebot wrote:
Adding GC pointer type does not enable anything that you can't
do write now for high-level applications and does not help at
all low-level applications. It is niche
On Wednesday, 28 May 2014 at 17:27:20 UTC, Dicebot wrote:
Adding GC pointer type does not enable anything that you can't
do write now for high-level applications and does not help at
all low-level applications. It is niche solution.
A niche solution is fine by me. Etienne has expressed
On Wednesday, 28 May 2014 at 17:39:21 UTC, Dicebot wrote:
Get this into upstream and you will have dozens unhappy about
updating for their code. It is never that simple.
It doesn't have to be in upstream. It could be an experimental
compiler implemented in pure D. I would back that, if
On Tuesday, 27 May 2014 at 02:52:48 UTC, Etienne Cimon wrote:
I've been looking at the GC and found that the main problem is
that there's no clear information about the pointers. At least
smart pointers have some info inside them but GC pointers are
completely plain 4-8 bytes and nothing else.
On Tuesday, 27 May 2014 at 03:26:33 UTC, Etienne Cimon wrote:
On 2014-05-26 23:19, Daniel Murphy wrote:
Etienne Cimon wrote in message
news:lm0um0$tgh$1...@digitalmars.com...
I think everything everywhere would have to change for this
to be
possible.
Sounds like never gonna happen.
In
On 2014-05-27 3:56 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On 64 bit platform 8 bytes is sufficient if you control the allocator:
1. Avoid allocating non-GC memory from specific address range.
2. Set a max-size for GC allocated objects.
Then the test becomes this:
On 2014-05-27 9:52 AM, Idan Arye wrote:
Please, no apostrophe. It'll mess syntax highlighters, and possible
indenters.
How about #?
void# ptr;
void## ptr2 = ptr;
assert(sizeof(ptr) == size_t + 3);
assert(szptr_t == sizeof(ptr));
szptr_t ptr2Val = cast(szptr_t) ptr;
char magicNum =
On Tuesday, 27 May 2014 at 13:58:26 UTC, Etienne wrote:
That's true, though you still need the thread ID for references
to pointers and you need to be able to pass those pointers to C.
I am not really sure how useful references to gc-pointers is. I
certainly would trade them in for multiple
On 2014-05-27 10:18 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 27 May 2014 at 13:58:26 UTC, Etienne wrote:
That's true, though you still need the thread ID for references to
pointers and you need to be able to pass those pointers to C.
I am not really sure
On Tuesday, 27 May 2014 at 14:42:34 UTC, Etienne wrote:
I think the GC is the future of D considering it's embedded to
the very core of the language, and compatibility with C code is
... elementary.
Well, but then I think you should be required to do manual
tracking while it is being
On 2014-05-27 10:54 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Tuesday, 27 May 2014 at 14:42:34 UTC, Etienne wrote:
I think the GC is the future of D considering it's embedded to the
very core of the language, and compatibility with C code is ...
elementary.
Well,
On Tuesday, 27 May 2014 at 16:47:38 UTC, Etienne wrote:
You're right, it's obviously easier to keep it as the same
pointer syntax but hijack the stdlib malloc functions to
forcibly go through the GC.
That is an option, and having a hijacked malloc would probably
also make it possible to
but I believe
it wouldn't stay low-cpu in a 128 GB of RAM server with 3GB/s of memory
traffic with a wide range of memory segment sizes.
I think a decent proposal would be to
1- Introduce a new GC pointer type, e.g. a void' (its an apostrophee)
used also in classes which implicitely converts
On 2014-05-26 23:15, Brian Schott wrote:
On Tuesday, 27 May 2014 at 02:52:48 UTC, Etienne Cimon wrote:
void' (its an apostrophee)
You mean the beginning of a character literal?
I think everything everywhere would have to change for this to be
possible.
I don't think we want to do that.
On Tuesday, 27 May 2014 at 02:52:48 UTC, Etienne Cimon wrote:
void' (its an apostrophee)
You mean the beginning of a character literal?
I think everything everywhere would have to change for this to
be possible.
I don't think we want to do that.
Etienne Cimon wrote in message news:lm0um0$tgh$1...@digitalmars.com...
I think everything everywhere would have to change for this to be
possible.
Sounds like never gonna happen.
On 2014-05-26 22:52, Etienne Cimon wrote:
2- For reference pointers to a GC pointer, void' would add a thread ID
and magic number to better identify them during collection, and to avoid
stopping the whole world to dereference them
Forgot to mention, but this not only avoids stopping the whole
On 2014-05-26 23:19, Daniel Murphy wrote:
Etienne Cimon wrote in message news:lm0um0$tgh$1...@digitalmars.com...
I think everything everywhere would have to change for this to be
possible.
Sounds like never gonna happen.
In terms of logic it's not that complicated, I could change DMD,
25 matches
Mail list logo
