I don't think I like D 2.0 over 1.0. Before you all run out to get me some
tissue, I figured I'd explain my
rationale.
The cool parts:
Closures are great.
I like that we moved D execution to a TLS.
The bad parts:
D still takes 80kb just to print "hello world" to the prompt. When are
Daniel:
I answer to just the things I know and understand, and I leave the other points
to other people, sorry.
> D still takes 80kb just to print "hello world" to the prompt.
When D2 is out of alpha for some time, I think devs will start to think about
this problem too. Currently it's low pri
Mon, 18 Jan 2010 00:36:47 -0500, bearophile wrote:
> What if
> tomorrow the registers become 256 or 1024 bits wide? D language must be
> used 10 years from now, when you have 2048 bits wide registers too, you
> can't keep adding wider and wider built in types. It's better to have a
> way to repres
"Daniel" wrote in message
news:hj0pvc$2si...@digitalmars.com...
>
Haven't we already had enough posts about "I don't like D2 because it
doesn't add *enough* stuff"? Fuck, people, this shit takes time!
> D still takes 80kb just to print "hello world" to the prompt.
We *just* had a large debate
Hello Nick,
2. Someone here has already made/posted a lib that does that. Don't
remember who though, maybe they'll reply here.
Me (at compile time, see reply to bearophile) and IIRC, someone else did
a runtime version.
Hello bearophile,
Daniel:
I also kind of hoped we'd see standard real world unit types in D.<
A mostly std lib solution can be acceptable,
Here's my (compile time) run at this:
http://www.dsource.org/projects/scrapple/browser/trunk/units
I'd be happy to fix up the ownership/license stuff
Daniel wrote:
I don't think I like D 2.0 over 1.0. Before you all run out to get me some
tissue, I figured I'd explain my
rationale.
[snip]
Things D missed:
cent and ucent should be available via SSE. Over 97% of computers now have it
and I still can't even assign to an
SSE register?
SSE
BCS:
> http://www.dsource.org/projects/scrapple/browser/trunk/units
With a little more compiler support to improve the syntax this stuff can be
more usable.
Is the usage of units common enough and important enough to deserve a bit of
compiler/language support? (I don't know yet what a nice synta
Nick Sabalausky Wrote:
> "Daniel" wrote in message
> news:hj0pvc$2si...@digitalmars.com...
> >
>
> Haven't we already had enough posts about "I don't like D2 because it
> doesn't add *enough* stuff"? Fuck, people, this shit takes time!
>
> > D still takes 80kb just to print "hello world" to
Daniel wrote:
I also kind of hoped we'd see standard real world unit types in D. Like sqft,
meters, ohms, kg, L, Hz, seconds,
etc. native to D. Being able to intrinsically convert types between these
things would make D the most
approachable General Programming Language for real world problem
Mon, 18 Jan 2010 02:05:14 -0500, Nick Sabalausky wrote:
> "Daniel" wrote in message
> news:hj0pvc$2si...@digitalmars.com...
>>
>>
> Haven't we already had enough posts about "I don't like D2 because it
> doesn't add *enough* stuff"? Fuck, people, this shit takes time!
>
>> D still takes 80kb jus
Am 18.01.2010, 12:08 Uhr, schrieb Walter Bright
:
Here it is:
// by Oskar Linde Aug 2006
// This is just a quick hack to test
// IFTI operators opMul and opDel
Wow that looks very neat.
Couldn't/Shouldn't that be added to phobos?
Nick Sabalausky wrote:
[snip]
It's been no worse at threading than C/C++ for quite some time. It's just
starting to have a threading model that kicks the crap out of the threading
in the vast majority of languages out there.
BTW, that effort is going quite well. For example, a producer-consume
Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
[snip]
It's been no worse at threading than C/C++ for quite some time. It's
just starting to have a threading model that kicks the crap out of the
threading in the vast majority of languages out there.
BTW, that effort is going quite well. For
"retard" wrote in message
news:hj1hfe$1bp...@digitalmars.com...
> Mon, 18 Jan 2010 02:05:14 -0500, Nick Sabalausky wrote:
>
>> "Daniel" wrote in message
>> news:hj0pvc$2si...@digitalmars.com...
>>>
>>>
>> Haven't we already had enough posts about "I don't like D2 because it
>> doesn't add *enoug
Hello Walter,
Daniel wrote:
I also kind of hoped we'd see standard real world unit types in D.
Like sqft, meters, ohms, kg, L, Hz, seconds,
etc. native to D. Being able to intrinsically convert types between
these things would make D the most
approachable General Programming Language for re
Mon, 18 Jan 2010 19:43:54 +, BCS wrote:
> Hello Walter,
>
>> Daniel wrote:
>>
>>> I also kind of hoped we'd see standard real world unit types in D.
>>> Like sqft, meters, ohms, kg, L, Hz, seconds,
>>>
>>> etc. native to D. Being able to intrinsically convert types between
>>> these things
Nick Sabalausky wrote:
Right, but like I had said below that, D isn't really usable for embedded
ATM, so until that happens (and I'm *really* anxious to see that happen), D
is still desktop-only, and even on the lowest-end desktops 80k is nothing.
I didn't know you were an embedded systems dev
Nick Sabalausky wrote:
I can totally accept that 486 in particular is pretty much dead, but unless
there's some specific advantage that can be only be gained by breaking 486
support, I see no reason for "It supports 486" to be something worth whining
about.
The compiler does a pretty good job
retard wrote:
Mon, 18 Jan 2010 19:43:54 +, BCS wrote:
Hello Walter,
Daniel wrote:
I also kind of hoped we'd see standard real world unit types in D.
Like sqft, meters, ohms, kg, L, Hz, seconds,
etc. native to D. Being able to intrinsically convert types between
these things would make
BCS wrote:
Hello bearophile,
Daniel:
I also kind of hoped we'd see standard real world unit types in D.<
A mostly std lib solution can be acceptable,
Here's my (compile time) run at this:
http://www.dsource.org/projects/scrapple/browser/trunk/units
I'd be happy to fix up the ownership/l
"Walter Bright" wrote in message
news:hj2ef2$4e...@digitalmars.com...
> Nick Sabalausky wrote:
>> Right, but like I had said below that, D isn't really usable for embedded
>> ATM, so until that happens (and I'm *really* anxious to see that happen),
>> D is still desktop-only, and even on the lo
Hello bearophile,
BCS:
http://www.dsource.org/projects/scrapple/browser/trunk/units
With a little more compiler support to improve the syntax this stuff
can be more usable.
Is the usage of units common enough and important enough to deserve a
bit of compiler/language support? (I don't know
Hello retard,
I also have a Core i7. Jeff Atwood has one
(http://www.codinghorror.com/ blog/archives/001316.html) - and he
represents the average Joe Six-pack developer.
That's fine as long as you are writing code for developers. If you are writing
code for users (the other 599M people in the
Walter Bright wrote:
> Nick Sabalausky wrote:
>> Right, but like I had said below that, D isn't really usable for
>> embedded ATM, so until that happens (and I'm *really* anxious to see
>> that happen), D is still desktop-only, and even on the lowest-end
>> desktops 80k is nothing.
>
> I didn't kn
Andrei Alexandrescu wrote:
> Andrei Alexandrescu wrote:
>> Nick Sabalausky wrote:
>> [snip]
>>> It's been no worse at threading than C/C++ for quite some time. It's
>>> just starting to have a threading model that kicks the crap out of
>>> the threading in the vast majority of languages out there.
Jérôme M. Berger wrote:
Embedded x86 is an oxymoron. Yes, I know, it exists (and btw, 8
years ago they were still selling 486s as "embedded" processors) but
mostly it doesn't need any special support (except possibly on the
binary size front and even there 80k is nothing to the XXX megaby
== Quote from "J�r�me_M._Berger" (jeber...@free.fr)'s article
> PS: At work, we mustn't use C++ because:
> - It's slow;
> - Its standard library is too big (100k);
> - In a future product, we might want to reuse this module and not
> have C++ (Oh, yes I didn't tell you that we *do* have the C++ std
Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
[snip]
It's been no worse at threading than C/C++ for quite some time. It's
just starting to have a threading model that kicks the crap out of
the threading in the vast majority of languages ou
dsimcha wrote:
This is a great point and deserves to be highlighted: D was meant to be a
better
C++, not a better C. If someone won't use C++ instead of C (apparently there
are
a decent amount of these people), then there's not a snowball's chance in hell
they'd use D, even if we fixed the bi
On 01/18/2010 11:31 PM, Walter Bright wrote:
Jérôme M. Berger wrote:
Embedded x86 is an oxymoron. Yes, I know, it exists (and btw, 8
years ago they were still selling 486s as "embedded" processors) but
mostly it doesn't need any special support (except possibly on the
binary size front and even
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> Also, if you're only writing a few K of code, D's advantages aren't that
> compelling over C (and neither are C++'s). It's when the size of the
> program increases that D's strengths really begin to dominate.
For small proj
Lars T. Kyllingstad wrote:
> retard wrote:
>> Mon, 18 Jan 2010 19:43:54 +, BCS wrote:
>>
>>> It might be a case of NIH, but that doesn't handle fractional units (for
>>> example MPa*m^1/2 is used in fracture mechanics and I suspect that they
>>> are fairly common as intermediate values in solvi
Walter Bright:
> Also, if you're only writing a few K of code, D's advantages aren't that
> compelling over C (and neither are C++'s). It's when the size of the
> program increases that D's strengths really begin to dominate.
I don't agree at all. D is (and has to be) fitter for short programs t
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Also, if you're only writing a few K of code, D's advantages aren't that
compelling over C (and neither are C++'s). It's when the size of the
program increases that D's strengths really begin to dominate.
F
Tue, 19 Jan 2010 01:52:24 -0800, Walter Bright wrote:
> dsimcha wrote:
>> == Quote from Walter Bright (newshou...@digitalmars.com)'s article
>>> Also, if you're only writing a few K of code, D's advantages aren't
>>> that compelling over C (and neither are C++'s). It's when the size of
>>> the pro
Walter Bright, el 18 de enero a las 14:31 me escribiste:
> > More seriously, I don't expect D to see much usage in the embedded
> >market unless it becomes a huge success on the PC first (if then).
> >But nothing you can do on the technical front will change that: it's
> >mostly due to prejudic
Walter Bright wrote:
> Jérôme M. Berger wrote:
>> Embedded x86 is an oxymoron. Yes, I know, it exists (and btw, 8
>> years ago they were still selling 486s as "embedded" processors) but
>> mostly it doesn't need any special support (except possibly on the
>> binary size front and even there 80k
"Leandro Lucarella" wrote in message
news:20100119173057.gd14...@llucax.com.ar...
Walter Bright, el 18 de enero a las 14:31 me escribiste:
> More seriously, I don't expect D to see much usage in the embedded
>market unless it becomes a huge success on the PC first (if then).
>But nothing you
== Quote from Craig Black (craigbla...@cox.net)'s article
> I would have to agree and this is one of my causes for hesisation in
> adopting D. The code I write requires the highest performance possible. I
> am concerned that when I port it over to D, I will have to avoid using a lot
> of D featur
Craig Black, el 19 de enero a las 17:27 me escribiste:
>
> "Leandro Lucarella" wrote in message
> news:20100119173057.gd14...@llucax.com.ar...
> >Walter Bright, el 18 de enero a las 14:31 me escribiste:
> >>> More seriously, I don't expect D to see much usage in the embedded
> >>>market unless it
Leandro Lucarella wrote:
Craig Black, el 19 de enero a las 17:27 me escribiste:
"Leandro Lucarella" wrote in message
news:20100119173057.gd14...@llucax.com.ar...
Walter Bright, el 18 de enero a las 14:31 me escribiste:
More seriously, I don't expect D to see much usage in the embedded
market
"Andrei Alexandrescu" wrote in message
news:hj5llq$tq...@digitalmars.com...
Leandro Lucarella wrote:
Craig Black, el 19 de enero a las 17:27 me escribiste:
"Leandro Lucarella" wrote in message
news:20100119173057.gd14...@llucax.com.ar...
Walter Bright, el 18 de enero a las 14:31 me escribi
Andrei Alexandrescu, el 19 de enero a las 17:18 me escribiste:
> >>I would have to agree and this is one of my causes for hesisation in
> >>adopting D. The code I write requires the highest performance
> >>possible. I am concerned that when I port it over to D, I will have
> >>to avoid using a lo
Craig Black:
>I would have to agree and this is one of my causes for hesisation in adopting
>D. The code I write requires the highest performance possible. I am
>concerned that when I port it over to D, I will have to avoid using a lot of D
>features that use the GC (built-in arrays, closures
Andrei Alexandrescu:
> I'd love -nogc. Then we can think of designing parts of Phobos to work
> under that regime.
But you must do this with lot of care: programmers coming from C++ will be
tempted to write code that uses those GC-free parts of Phobos a lot, the end
result will be a lot of D co
Hello bearophile,
Andrei Alexandrescu:
I'd love -nogc. Then we can think of designing parts of Phobos to
work under that regime.
But you must do this with lot of care: programmers coming from C++
will be tempted to write code that uses those GC-free parts of Phobos
a lot, the end result will
BCS:
> > A better strategy is first of all to improve a lot the D GC, if
> That's true regardless :)
I don't agree, because that idea of mine can be wrong :-)
What I was saying is that first you improve the GC performance (if necessary
modifying the language too) and you don't write parts of Pho
bearophile wrote:
Andrei Alexandrescu:
I'd love -nogc. Then we can think of designing parts of Phobos to work
under that regime.
But you must do this with lot of care: programmers coming from C++ will be
tempted to write code that uses those GC-free parts of Phobos a lot, the end
result will
Andrei Alexandrescu:
>With such a system in place, object.d can essentially gain entire control
>about an entire program's memory management policy.<
This is interesting, thank you for your answer.
Today you have to design a language not just for what's good for the single
programmer, and not e
Tue, 19 Jan 2010 23:17:44 -0800, Andrei Alexandrescu wrote:
> Walter and I are very convinced that the approach based on
> rewriting/lowering is very promising.
This sounds really good. I'm sure this could be extended to other built-
in types as well.
Am 20.01.2010 12:42, schrieb retard:
Tue, 19 Jan 2010 23:17:44 -0800, Andrei Alexandrescu wrote:
Walter and I are very convinced that the approach based on
rewriting/lowering is very promising.
This sounds really good. I'm sure this could be extended to other built-
in types as well.
i do
dennis luehring Wrote:
> Am 20.01.2010 12:42, schrieb retard:
> > Tue, 19 Jan 2010 23:17:44 -0800, Andrei Alexandrescu wrote:
> >
> >> Walter and I are very convinced that the approach based on
> >> rewriting/lowering is very promising.
> >
> > This sounds really good. I'm sure this could be ext
bearophile, el 20 de enero a las 01:51 me escribiste:
> A better strategy is first of all to improve a lot the D GC
Is not a better strategy, is another strategy. Improving the GC is as
important as (or even more important than) having a -nogc option. But an
extremely efficient GC will not be suit
Andrei Alexandrescu, el 19 de enero a las 23:17 me escribiste:
> bearophile wrote:
> >Andrei Alexandrescu:
> >>I'd love -nogc. Then we can think of designing parts of Phobos
> >>to work under that regime.
> >
> >But you must do this with lot of care: programmers coming from C++ will
> >be tempted t
dsimcha Wrote:
> == Quote from "Jérôme_M._Berger" (jeber...@free.fr)'s article
> > PS: At work, we mustn't use C++ because:
> > - It's slow;
> > - Its standard library is too big (100k);
> > - In a future product, we might want to reuse this module and not
> > have C++ (Oh, yes I didn't tell you t
By the way I forgot a link to 'Secure STL':
http://channel9.msdn.com/shows/Going+Deep/STL-Iterator-Debugging-and-Secure-SCL/
'nuff said.
Regards,
Ben
On Wed, 20 Jan 2010 14:18:52 +0100, Leandro Lucarella
wrote:
Again? RC is *not* -nogc, is -anothergc. And reference counting won't do
the trick unless you add a backing GC to free cycles. What I mean about
-nogc is *no* GC, is "please, mr compiler, give me an error when a GC
facility is used"
On Wed, Jan 20, 2010 at 10:18:52AM -0300, Leandro Lucarella wrote:
> > Walter and I talked for hours about a no-gc model for D, and the
> > conclusion was that with only a little compiler support, things can
> > be arranged such that swapping different object.d implementations,
> > the entire D all
Leandro Lucarella wrote:
Again? RC is *not* -nogc, is -anothergc.
I agree. With reference counting, you'd be no worse than a C++ project
that decided to use refcounted smart pointers for all allocated objects.
That sounds good to me.
And reference counting won't do
the trick unless you add
Leandro Lucarella Wrote:
> Andrei Alexandrescu, el 19 de enero a las 23:17 me escribiste:
> > bearophile wrote:
> > >Andrei Alexandrescu:
> > >>I'd love -nogc. Then we can think of designing parts of Phobos
> > >>to work under that regime.
> > >
> > >But you must do this with lot of care: programm
Craig Black wrote:
Leandro Lucarella Wrote:
Andrei Alexandrescu, el 19 de enero a las 23:17 me escribiste:
bearophile wrote:
Andrei Alexandrescu:
I'd love -nogc. Then we can think of designing parts of Phobos
to work under that regime.
But you must do this with lot of care: programmers comi
Hello bearophile,
BCS:
A better strategy is first of all to improve a lot the D GC, if
That's true regardless :)
I don't agree, because that idea of mine can be wrong :-)
What I was saying is that first you improve the GC performance (if
necessary modifying the language too) and you don't
Hello Andrei,
The nice part about refcounting is that for the most part you don't
need to cripple the language.
I think people are trying to say that disallowing use of GC stuff wouldn't
cripple the language.
Also there is one thing that -nogc would have over what you are talking about;
y
> I am a bit suspicious of this. GC scans can slow down a little, but I'm not
> seeing this as a big problem so far. You can test and benchmark some of your
> theories. A problem I've seen is caused by the not precise nature of the GC,
> wrong pointers keeping dead things alive.
Here's an inter
BCS wrote:
Hello Andrei,
The nice part about refcounting is that for the most part you don't
need to cripple the language.
I think people are trying to say that disallowing use of GC stuff
wouldn't cripple the language.
Well it's a fact that there would be fewer idioms and options
access
Danny Wilson, el 20 de enero a las 16:44 me escribiste:
> On Wed, 20 Jan 2010 14:18:52 +0100, Leandro Lucarella
> wrote:
>
> >Again? RC is *not* -nogc, is -anothergc. And reference counting won't do
> >the trick unless you add a backing GC to free cycles. What I mean about
> >-nogc is *no* GC, is
Andrei Alexandrescu, el 20 de enero a las 08:32 me escribiste:
> Leandro Lucarella wrote:
> >Again? RC is *not* -nogc, is -anothergc.
>
> I agree. With reference counting, you'd be no worse than a C++
> project that decided to use refcounted smart pointers for all
> allocated objects. That sounds
Leandro Lucarella wrote:
Danny Wilson, el 20 de enero a las 16:44 me escribiste:
On Wed, 20 Jan 2010 14:18:52 +0100, Leandro Lucarella
wrote:
Again? RC is *not* -nogc, is -anothergc. And reference counting won't do
the trick unless you add a backing GC to free cycles. What I mean about
-nogc
If you do this and use this style for a significant percentage (well, more
than 10-15% of it, unless it's less than 5000 lines long) of your whole
program, then you are using C++ in D, and I think it's better for you to
avoid using D, and to use C++ or C or asm :-)
No I think that even using a
"Andrei Alexandrescu" wrote in message
news:hj7vnu$200...@digitalmars.com...
BCS wrote:
Hello Andrei,
The nice part about refcounting is that for the most part you don't
need to cripple the language.
I think people are trying to say that disallowing use of GC stuff
wouldn't cripple the
Craig Black wrote:
"Andrei Alexandrescu" wrote in message
news:hj7vnu$200...@digitalmars.com...
BCS wrote:
Hello Andrei,
The nice part about refcounting is that for the most part you don't
need to cripple the language.
I think people are trying to say that disallowing use of GC stuff
w
Andrei Alexandrescu, el 20 de enero a las 17:39 me escribiste:
> Leandro Lucarella wrote:
> >Danny Wilson, el 20 de enero a las 16:44 me escribiste:
> >>On Wed, 20 Jan 2010 14:18:52 +0100, Leandro Lucarella
> >> wrote:
> >>
> >>>Again? RC is *not* -nogc, is -anothergc. And reference counting won't
Leandro Lucarella wrote:
> But I don't think people that *really* need to be in full control would
> see a RC GC as something tempting.
I don't need full control. I need RAII for dynamically allocated
objects, with destructors that really work. C++ with reference counting
can give me that and D
Leandro Lucarella wrote:
Andrei Alexandrescu, el 20 de enero a las 17:39 me escribiste:
Leandro Lucarella wrote:
Danny Wilson, el 20 de enero a las 16:44 me escribiste:
On Wed, 20 Jan 2010 14:18:52 +0100, Leandro Lucarella
wrote:
Again? RC is *not* -nogc, is -anothergc. And reference counti
Hello Andrei,
BCS wrote:
Also there is one thing that -nogc would have over what you are
talking about; you could use it on some modules and not others. If I
have some performance critical code where attempting to use the GC
would break it's perf contract, I can put it in it's own module and
c
BCS wrote:
Hello Andrei,
BCS wrote:
Also there is one thing that -nogc would have over what you are
talking about; you could use it on some modules and not others. If I
have some performance critical code where attempting to use the GC
would break it's perf contract, I can put it in it's own
Hello Andrei,
It's reasonable to say that you decide at application design level
what memory management approach you want to choose. That doesn't
fragment the community. The decision is similar to many others made at
the same level: libraries used, build flags, target platform(s),
pointer size (
BCS wrote:
Hello Andrei,
It's reasonable to say that you decide at application design level
what memory management approach you want to choose. That doesn't
fragment the community. The decision is similar to many others made at
the same level: libraries used, build flags, target platform(s),
po
On 2010-01-20 23:43:58 -0500, BCS said:
Why would having one chunk of code get checked for calls to the GC and
another not be any more complicated than mixing
malloc/free+add/removeRoot with normal GC? I'm beginning to wonder if
I'm calling for something different than other people are.
Wha
Hello Michel,
Theoretically, I think you should be able to avoid GC calls in a
function by using nothrow:
void func() nothrow {
auto a = new char[1]; // error: may throw
}
Unfortunately, it doesn't seem to always work:
void func(string a, string b) nothrow {
auto c = a ~ b; // no error?
}
But
Michel Fortin wrote:
On 2010-01-20 23:43:58 -0500, BCS said:
Why would having one chunk of code get checked for calls to the GC and
another not be any more complicated than mixing
malloc/free+add/removeRoot with normal GC? I'm beginning to wonder if
I'm calling for something different than o
Michel Fortin wrote:
But that's probably just a bug somewhere.
We decided that gc allocations are allowable inside a "nothrow"
function. The idea is that there are two classifications of exceptions -
recoverable and non-recoverable. "nothrow" only refers to recoverable
ones. Out of memory is
Leandro Lucarella wrote:
But I don't think people that *really* need to be in full control would
see a RC GC as something tempting. As long as there is an option to
(easily) avoid the GC, I'm happy, if you want to provice an RC
implementation then, great. I can't see an RC implementation fitting
Walter Bright:
> You can design a system that has "free these blobs of memory I'm keeping
> in reserve if I run out and hopefully that will be enough", but that
> strategy needs to be part of the gc itself, not user recovery code.
Do you mean that the D2 GC API needs to grow something to tell th
Andrei Alexandrescu, el 20 de enero a las 19:13 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el 20 de enero a las 17:39 me escribiste:
> >>Leandro Lucarella wrote:
> >>>Danny Wilson, el 20 de enero a las 16:44 me escribiste:
> On Wed, 20 Jan 2010 14:18:52 +0100, Leandro Luc
Andrei Alexandrescu, el 20 de enero a las 20:48 me escribiste:
> BCS wrote:
> >Hello Andrei,
> >
> >>BCS wrote:
> >>
> >>>Also there is one thing that -nogc would have over what you are
> >>>talking about; you could use it on some modules and not others. If I
> >>>have some performance critical cod
Walter Bright, el 21 de enero a las 02:15 me escribiste:
> Often programs that purportedly can recover from oom actually
> cannot, because they were never tested and the recovery code doesn't
> work.
Unless you use fault-injection. Is *not* that rare...
--
Leandro Lucarella (AKA luca)
Walter Bright, el 21 de enero a las 02:18 me escribiste:
> Leandro Lucarella wrote:
> >But I don't think people that *really* need to be in full control would
> >see a RC GC as something tempting. As long as there is an option to
> >(easily) avoid the GC, I'm happy, if you want to provice an RC
> >
Leandro Lucarella wrote:
Andrei Alexandrescu, el 20 de enero a las 19:13 me escribiste:
Leandro Lucarella wrote:
Andrei Alexandrescu, el 20 de enero a las 17:39 me escribiste:
Leandro Lucarella wrote:
Danny Wilson, el 20 de enero a las 16:44 me escribiste:
On Wed, 20 Jan 2010 14:18:52 +0100,
Leandro Lucarella wrote:
Andrei Alexandrescu, el 20 de enero a las 20:48 me escribiste:
BCS wrote:
Hello Andrei,
BCS wrote:
Also there is one thing that -nogc would have over what you are
talking about; you could use it on some modules and not others. If I
have some performance critical cod
Hello bearophile,
Walter Bright:
You can design a system that has "free these blobs of memory I'm
keeping in reserve if I run out and hopefully that will be enough",
but that strategy needs to be part of the gc itself, not user
recovery code.
Do you mean that the D2 GC API needs to grow some
Thu, 21 Jan 2010 18:38:07 +, BCS wrote:
> Hello bearophile,
>> (And it can be positive to define a standard way the D GC talks with
>> the virtual memory subsystem of the operationg system, to avoid useless
>> swaps from and to disk).
>
> IIRC virtual memeory and swapping has little or nothi
retard wrote:
On Linux the processes almost always stay on main memory, and only start
to fill swap when running out of main memory. So unless you have no swap
set up, OOM cannot happen unless the swap is >95% filled. OOM inside the
GC's virtual memory space can happen earlier, of course.
Yea
Walter Bright wrote:
retard wrote:
On Linux the processes almost always stay on main memory, and only
start to fill swap when running out of main memory. So unless you have
no swap set up, OOM cannot happen unless the swap is >95% filled. OOM
inside the GC's virtual memory space can happen ear
On Thu, Jan 21, 2010 at 2:43 PM, Andrei Alexandrescu
wrote:
> Walter Bright wrote:
>>
>> retard wrote:
>>>
>>> On Linux the processes almost always stay on main memory, and only start
>>> to fill swap when running out of main memory. So unless you have no swap set
>>> up, OOM cannot happen unless
> > It's much more complicated than that. What if a library returns an
> > object or an array to another library?
> The same that happens in C now, memory management is part of the interface
> and you should state if the returned object's memory is managed by the
> library or the user.
library or
Andrei Alexandrescu wrote:
> BCS wrote:
>> Hello Andrei,
>>
>>> BCS wrote:
>>>
Also there is one thing that -nogc would have over what you are
talking about; you could use it on some modules and not others. If I
have some performance critical code where attempting to use the GC
>>>
Andrei Alexandrescu wrote:
> Please stop spreading that information. Even if it has truth to it, it's
> not a reason to throw our hands in the air. In my field apps routinely
> encounter and handle the problem of running tight on memory.
I think in general it's better to detect and respond to low
Bill Baxter wrote:
On Thu, Jan 21, 2010 at 2:43 PM, Andrei Alexandrescu
wrote:
Walter Bright wrote:
retard wrote:
On Linux the processes almost always stay on main memory, and only start
to fill swap when running out of main memory. So unless you have no swap set
up, OOM cannot happen unless
1 - 100 of 124 matches
Mail list logo
