On Tuesday, 3 March 2015 at 02:05:08 UTC, Walter Bright wrote:
On 3/2/2015 11:38 AM, Martin Nowak wrote:
Compacting is indeed easy once we have a precise GC, and can
be done
partially, i.e. objects pointed to by the stack/register are
pinned.
Also unions.
Compacting doesn't solve the inhere
On 3/2/2015 11:38 AM, Martin Nowak wrote:
Compacting is indeed easy once we have a precise GC, and can be done
partially, i.e. objects pointed to by the stack/register are pinned.
Also unions.
On 02/25/2015 10:50 PM, deadalnix wrote:
>
> I don't think it make sens to completely discard the idea of barriers,
> especially when it come to write barrier on the immutable heap. At least
> that should certainly pay off.
Before the argument gets lost.
http://forum.dlang.org/post/mcqr3s$cmf$1..
On 02/26/2015 05:08 AM, Walter Bright wrote:
>
> A lot of benefit simply came from compacting all the remaining used
> allocations together, essentially defragging the memory.
Compacting is indeed easy once we have a precise GC, and can be done
partially, i.e. objects pointed to by the stack/regi
On Friday, 27 February 2015 at 15:53:18 UTC, ponce wrote:
On Thursday, 26 February 2015 at 14:22:01 UTC, Ola Fosheim
Grøstad wrote:
No. If I can't open a file I'd better not create a File
object in an invalid state. Invalid states defeats RAII.
This is the attitude I don't like, because it mea
On Fri, Feb 27, 2015 at 11:30:40PM +0100, Martin Nowak via Digitalmars-d wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/26/2015 01:50 AM, H. S. Teoh via Digitalmars-d wrote:
> > I don't know how typical this is, but in my own D code I tend to
> > use arrays a lot, and they do t
On Friday, 27 February 2015 at 22:32:06 UTC, Martin Nowak wrote:
On 02/26/2015 09:29 PM, deadalnix wrote:
Page fault ARE write barrier.
If done at kernel mode, it's too expensive anyhow.
As mentioned, it is not for the immutable part of the heap, for
obvious reasons.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/26/2015 09:29 PM, deadalnix wrote:
> Page fault ARE write barrier.
If done at kernel mode, it's too expensive anyhow.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBAgAGBQJU8PBSAAoJELJzgRYSuxk58EgP/1ZJMTJ4srl8A+67dr1jpKwv
vqZlsKvbZ0ZpP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/26/2015 01:50 AM, H. S. Teoh via Digitalmars-d wrote:
> I don't know how typical this is, but in my own D code I tend to
> use arrays a lot, and they do tend to add significant GC load. A
> recent performance improvement attempt in one of my proj
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/24/2015 10:53 AM, Walter Bright wrote:
>
> Even 10% makes it a no-go. Even 1%.
Write barriers would cost a low single digit, e.g. 3-4%.
While searching for ways to avoid the cost I found an interesting
alternative to generational GCs.
https://
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/22/2015 01:43 AM, Manu via Digitalmars-d wrote:
> D's GC is terrible, and after 6 years hanging out in this place, I
> have seen precisely zero development on the GC front. Nobody can
> even imagine, let alone successfully implement a GC that co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/22/2015 03:23 AM, Walter Bright wrote:
> - RC is slower overall
This claim isn't true for almost all applications when using a
conservative GC, except for programs that produce a lot of garbage and
have very few long-lived objects. The memory ba
On Friday, 27 February 2015 at 07:09:20 UTC, Benjamin Thaut wrote:
Am 27.02.2015 um 00:05 schrieb deadalnix:
Note that in D, you have union and all kind of crap like that,
so what
is writing a pointer is non obvious and so the tradeof is very
different
than it is in other languages.
To hav
On Thursday, 26 February 2015 at 14:22:01 UTC, Ola Fosheim
Grøstad wrote:
No. If I can't open a file I'd better not create a File object
in an invalid state. Invalid states defeats RAII.
This is the attitude I don't like, because it means that you
have to use pointers when you could just embed
On 2015-02-26 20:58, Walter Bright wrote:
It was a generational gc, I described earlier how it used page faults
instead of write barriers. I eventually removed the page fault system
because it was faster without it.
Instead you used?
--
/Jacob Carlborg
On 2015-02-26 21:45, Walter Bright wrote:
If you want some fun, take any system and fill up the disk drive to just
short of capacity. Now go about your work using the system.
You'll experience all kinds of delightful, erratic behavior, because
real world C code tends to ignore write failures an
Am 27.02.2015 um 00:05 schrieb deadalnix:
Note that in D, you have union and all kind of crap like that, so what
is writing a pointer is non obvious and so the tradeof is very different
than it is in other languages.
To have any chance of implementing a better GC in D I would simly start
of w
On Thursday, 26 February 2015 at 20:56:25 UTC, Walter Bright
wrote:
On 2/26/2015 12:29 PM, deadalnix wrote:
Page fault ARE write barrier.
When we all start debating what the meaning of "is" is, it's
time for me to check out.
You are the one playing that game. You said earlier you used MMU
On Thursday, 26 February 2015 at 21:17:57 UTC, Benjamin Thaut
wrote:
Am 26.02.2015 um 20:58 schrieb Walter Bright:
It was a generational gc, I described earlier how it used page
faults
instead of write barriers. I eventually removed the page fault
system
because it was faster without it.
P
On 2/26/2015 1:15 PM, Benjamin Thaut wrote:
Am 26.02.2015 um 21:39 schrieb Walter Bright:
You'll be paying that 10% penalty for every write access, not just for
GC data. D is not Java in that D has a lot of objects that are not on
the GC heap. Tradeoffs appropriate for Java are not necessarily
a
Am 26.02.2015 um 21:39 schrieb Walter Bright:
On 2/25/2015 1:27 PM, Benjamin Thaut wrote:
You seeing this completely one sided. Even if write barries make code
slower by
10% its a non issue if the GC collections get faster by 10% as well.
Then in
average the program will run at the same speed.
Am 26.02.2015 um 20:58 schrieb Walter Bright:
It was a generational gc, I described earlier how it used page faults
instead of write barriers. I eventually removed the page fault system
because it was faster without it.
Page faults are inferrior to compiler generated write barriers. Because
w
On 2/26/2015 12:29 PM, deadalnix wrote:
Page fault ARE write barrier.
When we all start debating what the meaning of "is" is, it's time for me to
check out.
On 2/25/2015 8:39 AM, Manu via Digitalmars-d wrote:
I'll take the possibility that an ignored
error code may not result in a hard-crash every time.
If you want some fun, take any system and fill up the disk drive to just short
of capacity. Now go about your work using the system.
You'll expe
On 2/25/2015 1:27 PM, Benjamin Thaut wrote:
You seeing this completely one sided. Even if write barries make code slower by
10% its a non issue if the GC collections get faster by 10% as well. Then in
average the program will run at the same speed.
You'll be paying that 10% penalty for every wr
On Thursday, 26 February 2015 at 19:58:56 UTC, Walter Bright
wrote:
On 2/25/2015 11:01 PM, Benjamin Thaut wrote:
What you are describing is a compacting GC and not a
generational GC. Please
just describe in words how you would do a generational GC
without write
barriers. Because just as deadaln
On Thursday, 26 February 2015 at 12:06:53 UTC, Baz wrote:
On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote:
https://developer.apple.com/news/?id=02202015a
Interesting...
Apple is dropping GC in favor of automatic reference counting.
What are the benefits of ARC over GC? Is it just abou
On Thursday, 26 February 2015 at 20:15:37 UTC, Walter Bright
wrote:
I don't really understand your point. Write barriers are
emitted for code that is doing a write.
That is exactly the point? When you don't write, you don't pay
for write barriers. It is fairly straightforward that the
argumen
On 2/25/2015 11:50 PM, Paulo Pinto wrote:
Maybe it failed the goal of having C++ developers fully embrace .NET, but it
achieved its goal of providing an easier way to integrate existing C++ code into
.NET applications, instead of the P/Invoke dance.
I wasn't referring to technical success. Ther
On 2/25/2015 9:01 PM, deadalnix wrote:
On Thursday, 26 February 2015 at 04:11:42 UTC, Walter Bright wrote:
On 2/25/2015 6:57 PM, deadalnix wrote:
You seems to avoid the important part of my message : write barrier tend to be
very cheap on immutable data. Because, as a matter of fact, you don't
On 2/25/2015 11:01 PM, Benjamin Thaut wrote:
What you are describing is a compacting GC and not a generational GC. Please
just describe in words how you would do a generational GC without write
barriers. Because just as deadalnix wrote, the problem is tracking pointers
within the old generation t
On 2/25/2015 8:51 PM, weaselcat wrote:
Is this implying you've begun work on a compacting D collector,
No.
or are you relating to your Java experiences?
Yes.
On Thursday, 26 February 2015 at 11:28:16 UTC, ponce wrote:
That's the problem with future/promises, you spent your time
explaining who waits for what instead of just writing what
things do.
There are many ways to do futures, but I don't think it is all
that complicated for the end user in mo
On Thursday, 26 February 2015 at 12:06:53 UTC, Baz wrote:
On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote:
https://developer.apple.com/news/?id=02202015a
Interesting...
Apple is dropping GC in favor of automatic reference counting.
What are the benefits of ARC over GC? Is it just abou
On Saturday, 21 February 2015 at 19:20:48 UTC, JN wrote:
https://developer.apple.com/news/?id=02202015a
Interesting...
Apple is dropping GC in favor of automatic reference counting.
What are the benefits of ARC over GC? Is it just about
predictability of resource freeing? Would ARC make sense
Am Thu, 26 Feb 2015 01:55:14 +1000
schrieb Manu via Digitalmars-d :
> >> I agree. I would suggest if ARC were proven possible, we would
> >> like, switch.
> >>
> >
> > I'd like to see ARC support in D, but I do not think it makes sense
> > as a default.
>
> Then we will have 2 distinct worlds
or:
f = open_file(…)
g = open_file(…)
h = open_file(…)
if( error(f,g,h) ) log_error
Also with async programming, futures/promises, the errors will
be delayed,
That's the problem with future/promises, you spent your time
explaining who waits for what instead of just writing what thin
On Wednesday, 25 February 2015 at 15:55:26 UTC, Manu wrote:
On 24 February 2015 at 10:36, deadalnix via Digitalmars-d
I'd like to see ARC support in D, but I do not think it makes
sense as a
default.
Then we will have 2 distinct worlds. There will be 2 kinds of D
code,
and they will be inco
On Thursday, 26 February 2015 at 00:54:57 UTC, Walter Bright
wrote:
On 2/25/2015 7:12 AM, Manu via Digitalmars-d wrote:
It does annoy me that I can't comment on the exceptions case,
...
COM is also an excellent candidate for consideration. If COM
works
well, then I imagine anything should w
Am 26.02.2015 um 05:08 schrieb Walter Bright:
On 2/25/2015 7:27 PM, deadalnix wrote:
On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:
Writing a generational collector for D is possible right now with no
language
changes, it's just that nobody has bothered to do it. Don't need
On Thursday, 26 February 2015 at 04:11:42 UTC, Walter Bright
wrote:
On 2/25/2015 6:57 PM, deadalnix wrote:
You seems to avoid the important part of my message : write
barrier tend to be
very cheap on immutable data. Because, as a matter of fact,
you don't write
immutable data (in fact you do to
On Thursday, 26 February 2015 at 04:08:32 UTC, Walter Bright
wrote:
On 2/25/2015 7:27 PM, deadalnix wrote:
On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright
wrote:
Writing a generational collector for D is possible right now
with no language
changes, it's just that nobody has bothere
On Thursday, 26 February 2015 at 04:08:32 UTC, Walter Bright
wrote:
On 2/25/2015 7:27 PM, deadalnix wrote:
On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright
wrote:
Writing a generational collector for D is possible right now
with no language
changes, it's just that nobody has bothere
On 2/25/2015 6:57 PM, deadalnix wrote:
You seems to avoid the important part of my message : write barrier tend to be
very cheap on immutable data. Because, as a matter of fact, you don't write
immutable data (in fact you do to some extent, but the amount of write is
minimal.
There is no reason
On 2/25/2015 7:27 PM, deadalnix wrote:
On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:
Writing a generational collector for D is possible right now with no language
changes, it's just that nobody has bothered to do it. Don't need write
barriers for it, either.
How are you pl
On 2/25/2015 5:19 PM, weaselcat wrote:
Rust currently has four or five pointer types(depending on how you define
pointer) and it seems to be quite popular.
We'll see. I've already seen some complaints about that aspect.
On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright
wrote:
Writing a generational collector for D is possible right now
with no language changes, it's just that nobody has bothered to
do it. Don't need write barriers for it, either.
How are you planning to track assignment a pointer
On Thursday, 26 February 2015 at 00:36:26 UTC, Walter Bright
wrote:
On 2/25/2015 1:50 PM, deadalnix wrote:
On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei
Alexandrescu wrote:
You seeing this completely one sided. Even if write barries
make code
slower by 10% its a non issue if the GC col
On 2/25/2015 4:50 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Feb 25, 2015 at 04:36:22PM -0800, Walter Bright via Digitalmars-d wrote:
On 2/25/2015 1:50 PM, deadalnix wrote:
On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:
You seeing this completely one sided. Eve
On Thursday, 26 February 2015 at 00:54:57 UTC, Walter Bright
wrote:
COM is also an excellent candidate for consideration. If COM
works
well, then I imagine anything should work.
Microsoft's latest C++ presents a model for this that I'm
generally
happy with; distinct RC pointer type. We could
On 2/25/2015 7:12 AM, Manu via Digitalmars-d wrote:
It does annoy me that I can't comment on the exceptions case,
That problem is easily correctable. But if you aren't interested in doing the
homework, you're stuck with accepting what I say about it :-)
That said, I'd still be surprised if
On Wed, Feb 25, 2015 at 04:36:22PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/25/2015 1:50 PM, deadalnix wrote:
> >On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:
> >>>You seeing this completely one sided. Even if write barries make
> >>>code slower by 10% its a
On 2/25/2015 1:50 PM, deadalnix wrote:
On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:
You seeing this completely one sided. Even if write barries make code
slower by 10% its a non issue if the GC collections get faster by 10% as
well. Then in average the program will
On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei
Alexandrescu wrote:
You seeing this completely one sided. Even if write barries
make code
slower by 10% its a non issue if the GC collections get faster
by 10% as
well. Then in average the program will run at the same speed.
H... not
On 2/25/15 1:27 PM, Benjamin Thaut wrote:
Am 24.02.2015 um 10:53 schrieb Walter Bright:
On 2/24/2015 1:30 AM, Tobias Pankrath wrote:
Are the meaningful performance comparisons
between the two pointer types that would enable us to estimate
how costly emitting those barriers in D would be?
Even
Am 24.02.2015 um 10:53 schrieb Walter Bright:
On 2/24/2015 1:30 AM, Tobias Pankrath wrote:
Are the meaningful performance comparisons
between the two pointer types that would enable us to estimate
how costly emitting those barriers in D would be?
Even 10% makes it a no-go. Even 1%.
D has to b
On Wednesday, 25 February 2015 at 16:39:38 UTC, Manu wrote:
This is precisely my complaint though. In a production
environment
where there are 10's, 100's of people working concurrently, it
is
absolutely unworkable that code can be crashing for random
reasons
that I don't care about all the ti
On Thu, Feb 26, 2015 at 02:39:28AM +1000, Manu via Digitalmars-d wrote:
> On 25 February 2015 at 09:02, ponce via Digitalmars-d
> wrote:
> > On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:
> >>
> >> This is going to sound really stupid... but do people actually use
> >> exceptions regular
On 25 February 2015 at 09:02, ponce via Digitalmars-d
wrote:
> On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:
>>
>> This is going to sound really stupid... but do people actually use
>> exceptions regularly?
>> I've never used one. When I encounter code that does, I just find it
>> reall
On 24 February 2015 at 10:36, deadalnix via Digitalmars-d
wrote:
> On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:
>>
>> This is going to sound really stupid... but do people actually use
>> exceptions regularly?
>
>
> I'd say exception are exceptional in most code. That being said, unles
On 24 February 2015 at 04:04, Andrei Alexandrescu via Digitalmars-d
wrote:
>
> I think RC is an important tool on our panoply. More so than Walter. But I
> have to say you'd do good to understand his arguments better; it doesn't
> seem you do.
The only argument I can't/haven't addressed is the ex
On Tuesday, 24 February 2015 at 23:02:14 UTC, ponce wrote:
One (big) problem about error code is that they do get ignored,
much too often. It's like manual memory management, everyone
think they can do it without errors, but mostly everyone fail
at it (me too, and you too).
Explicit return va
On Tuesday, 24 February 2015 at 23:49:21 UTC, Walter Bright wrote:
On 2/24/2015 11:07 AM, deadalnix wrote:
The page fault strategy is used by ML family language's GC and
they get really
good performance out of it. That being said, in ML like
language most things are
immutable, so they are a
On 2/24/2015 11:07 AM, deadalnix wrote:
The page fault strategy is used by ML family language's GC and they get really
good performance out of it. That being said, in ML like language most things are
immutable, so they are a
I wrote a gc for Java that used the page fault strategy. It was slower
On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:
This is going to sound really stupid... but do people actually
use
exceptions regularly?
I've never used one. When I encounter code that does, I just
find it
really annoying to debug. I've never 'gotten' exceptions. I'm
not sure
why erro
On 2/24/2015 5:28 AM, Wyatt wrote:
On Tuesday, 24 February 2015 at 09:53:19 UTC, Walter Bright wrote:
D has to be competitive in the most demanding environments.
But isn't that exactly the point? Garbage collected D is NOT competitive in
demanding environments.
Write barriers are not the a
On Tuesday, 24 February 2015 at 07:53:52 UTC, Jacob Carlborg
wrote:
On 2015-02-23 21:30, Walter Bright wrote:
Count me among those.
In Java, write barriers make sense because Java uses the GC for
everything. Pretty much every indirection is a GC reference.
This is not at all true with D code.
On Tuesday, 24 February 2015 at 09:53:19 UTC, Walter Bright wrote:
D has to be competitive in the most demanding environments.
But isn't that exactly the point? Garbage collected D is NOT
competitive in demanding environments.
-Wyatt
On Tuesday, 24 February 2015 at 13:07:38 UTC, Tobias Pankrath
wrote:
On Tuesday, 24 February 2015 at 12:31:06 UTC, Paulo Pinto
wrote:
Sorry about the caps, couldn't find a better way to emphasis.
Not sure where you found out the information about x86, or why
it should matter.
I found an (app
On Tuesday, 24 February 2015 at 12:31:06 UTC, Paulo Pinto wrote:
Sorry about the caps, couldn't find a better way to emphasis.
Not sure where you found out the information about x86, or why
it should matter.
I found an (apparently older) version of the documentation
earlier that looked exact
On Tuesday, 24 February 2015 at 11:08:59 UTC, Tobias Pankrath
wrote:
The latest implementation had a concurrent incremental
generational GC.
https://modula3.elegosoft.com/cm3/doc/help/cm3/gc.html
According to this they never had a concurrent or incremental GC
on x86.
Sorry about the caps,
The latest implementation had a concurrent incremental
generational GC.
https://modula3.elegosoft.com/cm3/doc/help/cm3/gc.html
According to this they never had a concurrent or incremental GC
on x86.
On Tuesday, 24 February 2015 at 09:30:33 UTC, Tobias Pankrath
wrote:
I suspect it would be a terrible performance hit.
It would be nice to have some numbers backing this up.
This the approach taken by Active Oberon and Modula-3.
Pointers are GC by default, but can be declared as untraced
p
On 2/24/2015 1:50 AM, Walter Bright wrote:
On 2/23/2015 11:53 PM, Jacob Carlborg wrote:
On 2015-02-23 21:30, Walter Bright wrote:
I suspect it would be a terrible performance hit.
It would be nice to have some numbers backing this up.
I've seen enough benchmarks that purport to show that Java
On 2/23/2015 11:57 PM, Jacob Carlborg wrote:
On 2015-02-22 21:48, Walter Bright wrote:
And I suspect that ARC is why they don't have exceptions.
Objective-C still has both ARC and exceptions. Although the documentation [1]
says that ARC is not exception safe by default, but it does have a fla
On 2/24/2015 1:30 AM, Tobias Pankrath wrote:
Are the meaningful performance comparisons
between the two pointer types that would enable us to estimate
how costly emitting those barriers in D would be?
Even 10% makes it a no-go. Even 1%.
D has to be competitive in the most demanding environment
On 2/23/2015 11:53 PM, Jacob Carlborg wrote:
On 2015-02-23 21:30, Walter Bright wrote:
Count me among those.
In Java, write barriers make sense because Java uses the GC for
everything. Pretty much every indirection is a GC reference.
This is not at all true with D code. But since the compiler
I suspect it would be a terrible performance hit.
It would be nice to have some numbers backing this up.
This the approach taken by Active Oberon and Modula-3.
Pointers are GC by default, but can be declared as untraced
pointers in code considered @system like in D.
Do they have concurr
On Tuesday, 24 February 2015 at 07:53:52 UTC, Jacob Carlborg
wrote:
On 2015-02-23 21:30, Walter Bright wrote:
Count me among those.
In Java, write barriers make sense because Java uses the GC for
everything. Pretty much every indirection is a GC reference.
This is not at all true with D code.
On 2015-02-22 21:48, Walter Bright wrote:
And I suspect that ARC is why they don't have exceptions.
Objective-C still has both ARC and exceptions. Although the
documentation [1] says that ARC is not exception safe by default, but it
does have a flag to enable it "-fobjc-arc-exceptions".
[1
On 2015-02-23 21:30, Walter Bright wrote:
Count me among those.
In Java, write barriers make sense because Java uses the GC for
everything. Pretty much every indirection is a GC reference.
This is not at all true with D code. But since the compiler can't know
that, it has to insert write barri
On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:
This is going to sound really stupid... but do people actually
use
exceptions regularly?
I'd say exception are exceptional in most code. That being said,
unless the compiler can PROVE that no exception is gonna be
thrown, you are stuck
On 2/22/2015 3:25 AM, Jacob Carlborg wrote:
* Most good GC implementations need some kind of barrier (read or write, don't
remember which). If I recall there are several people against this in the
community
Count me among those.
In Java, write barriers make sense because Java uses the GC for
Urgh. Product types masquerading as sum types. Give me a break
will ya. -- Andrei
1. The product solution is more pleasant to work with, if you
have no sugar for sum types like pattern matching.
2. It's the same as with exception specifications: Product types
make ignoring the error path eas
On 2/23/15 3:27 AM, Walter Bright wrote:
On 2/23/2015 1:50 AM, Manu via Digitalmars-d wrote:
1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in
time and
bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS.
This is
not an option for D.
This is going to sound reall
On Monday, 23 February 2015 at 12:30:55 UTC, Russel Winder wrote:
On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:
O[…]
This is going to sound really stupid... but do people actually
use
exceptions regularly?
I've never used one. When I encounter code that does, I just
find it
On Monday, 23 February 2015 at 12:30:55 UTC, Russel Winder wrote:
value and error code. C got this fairly wrong, Go gets it
fairly right.
It's the one feature about Go that makes Go code look really
ugly... So I guess this is a very subjective issue. Posix is
actually pretty consistent by ret
On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:
> O[…]
> This is going to sound really stupid... but do people actually use
> exceptions regularly?
> I've never used one. When I encounter code that does, I just find it
> really annoying to debug. I've never 'gotten' exceptions. I'm
On 2/23/2015 1:50 AM, Manu via Digitalmars-d wrote:
1. Increment and decrement, ESPECIALLY DECREMENT, is EXPENSIVE in time and
bloat because of exceptions. Swift does it by NOT HAVING EXCEPTIONS. This is
not an option for D.
This is going to sound really stupid... but do people actually use
exc
On 23 February 2015 at 20:24, Jakob Ovrum via Digitalmars-d
wrote:
> On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
>>
>> On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d
>>
>> wrote:
>>>
>>> On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:
I have no idea
On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d
wrote:
On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:
I have no idea where to start.
Start by making a ref counted type and see what the pain
points are.
All my re
On 23 February 2015 at 16:50, Walter Bright via Digitalmars-d
wrote:
> On 2/22/2015 9:53 PM, Manu via Digitalmars-d wrote:
>>
>> It's got nothing to do with doing work. ARC (or something like it) is
>> almost religiously opposed. We can't even have a reasonable
>> conversation about it, or really
On Monday, 23 February 2015 at 07:19:56 UTC, Paulo Pinto wrote:
Personally I think what matters is getting D's situation
regarding memory management sorted out, regardless out it will
look like in the end.
This is exactly right, either
1. The compiler takes care of allocation/deallocations a
On Monday, 23 February 2015 at 09:01:23 UTC, Daniel Murphy wrote:
"Ola Fosheim Grøstad" " wrote in message
news:hwwotfmkjvwsempqi...@forum.dlang.org...
I mean that the optimizer does not know what _rc is. The
optimizer can only elide what it can prove, by sound logic,
not by assumptions.
Th
"Ola Fosheim Grøstad" " wrote in message
news:hwwotfmkjvwsempqi...@forum.dlang.org...
I mean that the optimizer does not know what _rc is. The optimizer can
only elide what it can prove, by sound logic, not by assumptions.
The whole point of compiler-supported RC is that the optimizer can mak
On Monday, 23 February 2015 at 08:50:28 UTC, Walter Bright wrote:
On 2/23/2015 12:33 AM, Tobias Pankrath wrote:
On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim
Grøstad wrote:
Thanks to the messed up modular arithmetics that D has chosen
you cannot
assume the a non-shared live object do
On Monday, 23 February 2015 at 08:33:59 UTC, Tobias Pankrath
wrote:
You mean when there are more than 2^64 references to the object?
I mean that the optimizer does not know what _rc is. The
optimizer can only elide what it can prove, by sound logic, not
by assumptions.
On Monday, 23 February 2015 at 06:51:21 UTC, Walter Bright wrote:
4. DIP25, now implemented, is a way to address memory safety in
D while using reference counting. Any proposal for ARC needs
to, at least, understand that proposal.
I asked further up in the thread if coroutines can hold onto
"
On 2/23/2015 12:33 AM, Tobias Pankrath wrote:
On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim Grøstad wrote:
Thanks to the messed up modular arithmetics that D has chosen you cannot
assume the a non-shared live object does not have a rc==0 due to wrapping
integers, in the general case.
On Monday, 23 February 2015 at 08:27:52 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 23 February 2015 at 01:41:17 UTC, Adam D. Ruppe
wrote:
On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
All my ref counting types fiddle with the ref in every
assignment, or every function call and return
1 - 100 of 149 matches
Mail list logo
