On Thu, 2014-07-24 at 11:39 +, Paulo Pinto via Digitalmars-d wrote:
[…]
In this specific case yes, but as I mentioned there are lots of
uses cases being reported.
It turns out to be a known fact even in Gradleware. Hans mentions it
specifically inhis vision for the future document of a
On Sunday, 27 July 2014 at 08:24:44 UTC, Russel Winder via
Digitalmars-d wrote:
On Thu, 2014-07-24 at 11:39 +, Paulo Pinto via
Digitalmars-d wrote:
[…]
In this specific case yes, but as I mentioned there are lots
of uses cases being reported.
It turns out to be a known fact even in
On Sun, 2014-07-27 at 12:51 +, Chris via Digitalmars-d wrote:
On Sunday, 27 July 2014 at 08:24:44 UTC, Russel Winder via
Digitalmars-d wrote:
[…]
He also mentions that the C/C++ build aspects of Gradle are to
be used
by the Android NDK folk. I already asked them about including D
On 7/23/2014 1:46 AM, Russel Winder via Digitalmars-d wrote:
I think you'll find HotSpot evolved from a Smalltalk JIT originally.
Borland and Semantec had JVM JITs as well, Sun even licenced the
Semantec one for a while.
Fun fact: the guy who wrote Symantec's JVM JIT, Steve Russell, is the
On Wed, 2014-07-23 at 22:58 +0200, Paulo Pinto via Digitalmars-d wrote:
[…]
So far I could only find
Looking into the JVM Crystal Ball
http://www.parleys.com/play/524f6b5be4b0a43ac12123a9/about
Between 00:40:00 and 00:45:50, compilation gets discussed, including AOT.
Not the ones about
On Wed, 2014-07-23 at 21:32 +0200, Paulo Pinto via Digitalmars-d wrote:
[…]
I only tried Graddle because of Android Studio, it makes so bad use of
hardware resources, pegging my i7 and core duo processors, that I
returned to Eclipse + ADT on the same day.
I have not tried Android Studio
On Wed, 2014-07-23 at 14:37 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/23/14, 12:23 PM, Russel Winder via Digitalmars-d wrote:
BTW what's with the rabbit and the monkey?
He promised his kid they'll go on an adventure with daddy. A really nice
touch. I might steal it for my
On Thursday, 24 July 2014 at 08:34:30 UTC, Russel Winder via
Digitalmars-d wrote:
On Wed, 2014-07-23 at 21:32 +0200, Paulo Pinto via
Digitalmars-d wrote:
[…]
The situation is so bad it was even mentioned at this Google
IO Android developer tools talk.
I think this will be a JetBrains
On Thu, 2014-07-24 at 09:38 +, Paulo Pinto via Digitalmars-d wrote:
[…]
Nope, Gradle, as shown by the CPU usage on the task manager.
I am surprised, but data always trumps opinion.
--
Russel.
=
Dr Russel Winder
On Thursday, 24 July 2014 at 11:01:35 UTC, Russel Winder via
Digitalmars-d wrote:
On Thu, 2014-07-24 at 09:38 +, Paulo Pinto via
Digitalmars-d wrote:
[…]
Nope, Gradle, as shown by the CPU usage on the task manager.
I am surprised, but data always trumps opinion.
One of the first
On Thu, 2014-07-24 at 11:09 +, Paulo Pinto via Digitalmars-d wrote:
On Thursday, 24 July 2014 at 11:01:35 UTC, Russel Winder via
Digitalmars-d wrote:
On Thu, 2014-07-24 at 09:38 +, Paulo Pinto via
Digitalmars-d wrote:
[…]
Nope, Gradle, as shown by the CPU usage on the task
On Thursday, 24 July 2014 at 11:35:09 UTC, Russel Winder via
Digitalmars-d wrote:
On Thu, 2014-07-24 at 11:09 +, Paulo Pinto via
Digitalmars-d wrote:
On Thursday, 24 July 2014 at 11:01:35 UTC, Russel Winder via
Digitalmars-d wrote:
On Thu, 2014-07-24 at 09:38 +, Paulo Pinto via
On Tue, 2014-07-22 at 10:55 +, Paulo Pinto via Digitalmars-d wrote:
[…]
The JVM JIT was originally targeted to SELF, not Java.
I think you'll find HotSpot evolved from a Smalltalk JIT originally.
Borland and Semantec had JVM JITs as well, Sun even licenced the
Semantec one for a while.
[…]
On Wednesday, 23 July 2014 at 08:46:32 UTC, Russel Winder via
Digitalmars-d wrote:
On Tue, 2014-07-22 at 10:55 +, Paulo Pinto via
Digitalmars-d wrote:
[…]
I avoid touching Gradle.
Your loss!
For others: Gradle is becoming the de facto standard build
framework for
JVM-based things
On Wednesday, 23 July 2014 at 08:46:32 UTC, Russel Winder via
Digitalmars-d wrote:
On Tue, 2014-07-22 at 10:55 +, Paulo Pinto via
Digitalmars-d wrote:
[…]
The JVM JIT was originally targeted to SELF, not Java.
I think you'll find HotSpot evolved from a Smalltalk JIT
originally.
Borland
The JVM JIT was originally targeted to SELF, not Java.
Yes, that's right. The guys that developed Self (David Ungar et
al.) then set out to develop a high-performance typed Smalltalk
using the optimization techniques they developed for Self. The
Smalltalk system never hit the market as the
On Wednesday, 23 July 2014 at 09:16:57 UTC, John Colvin wrote:
On Wednesday, 23 July 2014 at 08:46:32 UTC, Russel Winder via
Digitalmars-d wrote:
On Tue, 2014-07-22 at 10:55 +, Paulo Pinto via
Digitalmars-d wrote:
[…]
The JVM JIT was originally targeted to SELF, not Java.
I think you'll
On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote:
For others: Gradle is becoming the de facto standard build framework for
JVM-based things and also Android.
Uhm, I'm literally right now in a talk on Buck
(https://github.com/facebook/buck) at OSCON. -- Andrei
On 7/23/14, 11:40 AM, Andrei Alexandrescu wrote:
On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote:
For others: Gradle is becoming the de facto standard build framework for
JVM-based things and also Android.
Uhm, I'm literally right now in a talk on Buck
On Wed, 2014-07-23 at 11:45 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/23/14, 11:40 AM, Andrei Alexandrescu wrote:
On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote:
For others: Gradle is becoming the de facto standard build framework for
JVM-based things and also
On Wed, 2014-07-23 at 09:11 +, Paulo Pinto via Digitalmars-d wrote:
[…]
I will happily use it when it gets to the same execution speed
and hardware resources than Eclipse + ADT is currently using.
The way I work with Gradle is to generate Eclipse or IntelliJ IDEA
projects if I am going to
On Wed, 2014-07-23 at 09:16 +, John Colvin via Digitalmars-d wrote:
[…]
I am suspicious. I understand that a situation can be contrived
such that C will lose, but in normal, sensible code the only
language I've ever seen reliably beat C is FORTRAN.
For my data parallel computations, I
Am 23.07.2014 21:23, schrieb Russel Winder via Digitalmars-d:
On Wed, 2014-07-23 at 11:45 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/23/14, 11:40 AM, Andrei Alexandrescu wrote:
On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote:
For others: Gradle is becoming the de
On Wednesday, 23 July 2014 at 09:16:57 UTC, John Colvin wrote:
I am suspicious. I understand that a situation can be contrived
such that C will lose, but in normal, sensible code the only
language I've ever seen reliably beat C is FORTRAN.
I'm reminded of when headlines came out saying PyPy
Am 23.07.2014 21:27, schrieb Russel Winder via Digitalmars-d:
On Wed, 2014-07-23 at 09:11 +, Paulo Pinto via Digitalmars-d wrote:
[…]
It was presented as such at JavaONE for possible future Java 9+
improvements.
I can try to dig out the presentation, if you wish.
Clearly I need to
On 7/23/14, 12:23 PM, Russel Winder via Digitalmars-d wrote:
BTW what's with the rabbit and the monkey?
He promised his kid they'll go on an adventure with daddy. A really nice
touch. I might steal it for my own talks. -- Andrei
On Wednesday, 23 July 2014 at 11:54:19 UTC, Atila Neves wrote:
http://benchmarksgame.alioth.debian.org/
There's no good reason for C to beat C++. Even if there were,
it would be simple to rewrite the C++ bottleneck in C style.
Likewise, there's no good reason for C to beat D either.
I was
On Wednesday, 23 July 2014 at 18:45:23 UTC, Andrei Alexandrescu
wrote:
On 7/23/14, 11:40 AM, Andrei Alexandrescu wrote:
On 7/23/14, 1:46 AM, Russel Winder via Digitalmars-d wrote:
For others: Gradle is becoming the de facto standard build
framework for
JVM-based things and also Android.
On Monday, 21 July 2014 at 18:31:46 UTC, Russel Winder via
Digitalmars-d wrote:
On Sun, 2014-07-20 at 16:40 +, Paulo Pinto via
Digitalmars-d wrote:
[…]
Java has AOT compilers available since the early days. Most
developers just tend to ignore them, because they are not part
of the free
On Tue, 2014-07-22 at 06:35 +, Paulo Pinto via Digitalmars-d wrote:
[…]
Yes it can, if developers bother to do PGO + AOT instead and
learn the compiler flags.
I used to have a stronger opinion on JIT, but given how many JITs
perform and do not actually use the hardware as they, in
On Tuesday, 22 July 2014 at 08:10:31 UTC, Russel Winder via
Digitalmars-d wrote:
On Tue, 2014-07-22 at 06:35 +, Paulo Pinto via
Digitalmars-d wrote:
[…]
Yes it can, if developers bother to do PGO + AOT instead and
learn the compiler flags.
I used to have a stronger opinion on JIT, but
On Friday, 18 July 2014 at 09:25:46 UTC, Chris wrote:
On Thursday, 17 July 2014 at 18:19:04 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 17, 2014 at 05:58:14PM +, Chris via
Digitalmars-d wrote:
On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via
Digitalmars-d
wrote:
[...]
On Sunday, 20 July 2014 at 12:30:02 UTC, Mike wrote:
Yes, I believe you are correct. I also believe there is even a
GCStub in the runtime that uses malloc without free. What's
missing is API documentation and examples that makes such
features accessible.
The existing functions should be
On Sun, 2014-07-20 at 16:40 +, Paulo Pinto via Digitalmars-d wrote:
[…]
Java has AOT compilers available since the early days. Most
developers just tend to ignore them, because they are not part of
the free package.
Also, it is not entirely clear that AOT optimization can beat JIT
On Monday, 21 July 2014 at 18:31:46 UTC, Russel Winder via
Digitalmars-d wrote:
On Sun, 2014-07-20 at 16:40 +, Paulo Pinto via
Digitalmars-d wrote:
[…]
Java has AOT compilers available since the early days. Most
developers just tend to ignore them, because they are not part
of the free
On Saturday, 19 July 2014 at 21:12:44 UTC, Walter Bright wrote:
3. slices become mostly unworkable, and slices are a fantastic
way to speed up a program
They are even more fantastic for speeding up programming.
I think that programmer time isn't included often enough in
discussions.
I
On 17 Jul 2014 13:40, w0rp via Digitalmars-d digitalmars-d@puremagic.com
wrote:
The key to making D's GC acceptable lies in two factors I believe.
1. Improve the implementation enough so that you will only be impacted by
GC in extermely low memory or real time environments.
2. Defer
On Sunday, 20 July 2014 at 08:41:16 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 17 Jul 2014 13:40, w0rp via Digitalmars-d
The key to making D's GC acceptable lies in two factors I
believe.
1. Improve the implementation enough so that you will only be
impacted by
GC in extermely low memory
On Sunday, 20 July 2014 at 11:44:56 UTC, Mike wrote:
Being able to specify an alternate memory manager at
compile-time, link-time and/or runtime would be most
advantageous, and probably put an end to the GC-phobia.
AFAIK, GC is not directly referenced in druntime, so you already
should be
On Sunday, 20 July 2014 at 12:07:47 UTC, Kagamin wrote:
On Sunday, 20 July 2014 at 11:44:56 UTC, Mike wrote:
Being able to specify an alternate memory manager at
compile-time, link-time and/or runtime would be most
advantageous, and probably put an end to the GC-phobia.
AFAIK, GC is not
On Thursday, 17 July 2014 at 14:05:02 UTC, Brian Rogoff wrote:
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
If D came without GC, it would have replaced C++ a long time
ago!
That's overly optimistic I think, but I believe that the
adoption rate would have been far greater for a D
On Thursday, 17 July 2014 at 19:14:06 UTC, Right wrote:
I'm rather fond of RAII, I find that I rarely every need
shared semantics.
I use a custom object model that allows for weak_ptrs to
unique_ptrs which I think removes some cases where people might
otherwise be inclined to use shared_ptr.
On 7/17/2014 5:06 PM, H. S. Teoh via Digitalmars-d wrote:
MyOutputRange sink; // allocate using whatever scheme you want
myInput.withoutTabs.copy(sink);
The algorithm itself doesn't need to know where the result will end up
-- sink could be stdout, in which case no
On 7/17/2014 11:44 AM, Russel Winder via Digitalmars-d wrote:
With C++ I am coming to grips with RAII management of the heap. With
Java, Groovy, Go and Python I rely on the GC doing a good job. I note
though that there is a lot of evidence that the Unreal folk developed a
garbage collector for
On 7/17/2014 11:17 AM, H. S. Teoh via Digitalmars-d wrote:
I don't think it will affect existing code (esp. given Walter's stance
on breaking changes!). Probably the old GC-based string functions will
still be around for backwards-compatibility. Perhaps some of them might
be replaced with non-GC
On 7/17/2014 10:47 PM, H. S. Teoh via Digitalmars-d wrote:
Deferring the allocation point to the top level has the advantage of
letting high-level user code decide what the allocation strategy should
be, rather than percolating that decision down the call graph to every
low-level function.
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
Just from watching a few of the DConf 2014 talks, if you want
performance you avoid the GC at all costs (even if that means
allocating into huge predefined buffers). Once you're going to
these lengths to avoid garbage collection it
On Thursday, 17 July 2014 at 18:19:04 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 17, 2014 at 05:58:14PM +, Chris via
Digitalmars-d wrote:
On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via
Digitalmars-d
wrote:
[...]
AFAIK some work still needs to be done with std.string;
On Friday, 18 July 2014 at 00:08:17 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 17, 2014 at 06:32:58PM +, Dicebot via
Digitalmars-d wrote:
On Thursday, 17 July 2014 at 18:22:11 UTC, H. S. Teoh via
Digitalmars-d
wrote:
Actually, I've realized that output ranges are really only
It appears still to be a general meme that performance required no GC
and GC mean poor performance. The debate has been restarted on the Go
mailing list under the banner go without garbage collector. The
response to will Go remove the garbage collector was somewhat
unequivocal: nope.
--
Russel.
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance required
no GC
and GC mean poor performance. The debate has been restarted on
the Go
mailing list under the banner go without garbage collector.
The
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance
required no GC
and GC mean poor performance. The debate has been restarted on
the Go
mailing list
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
That's good news in a way. If a big company accepts GC and the
Go crowd go with it (pardon the pun), then it will find more
acceptance (as Paulo pointed
currysoup wrote in message news:iustbzgyagrlbtnfc...@forum.dlang.org...
Once you're going to
these lengths to avoid garbage collection it begs the question,
why are you even using this language?
Because D has plenty of other things to offer.
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance
required no GC
and GC mean poor
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme
The key to making D's GC acceptable lies in two factors I believe.
1. Improve the implementation enough so that you will only be
impacted by GC in extermely low memory or real time environments.
2. Defer allocation more and more by using ranges and algorithms
more, and trust that compiler
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance required
no GC
and GC mean poor performance. The debate has been restarted on
the Go
mailing list under the banner go without garbage collector.
The
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
It's not about acceptance, it's about the reality that a GC
is not a universal solution to memory management.
Just from watching a few of the DConf 2014 talks, if you want
performance you avoid the GC at all costs (even if that means
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
Don't know if it's really a major concern or the favorite
weak spot that C++ et. al guys like to flog to death in order
to distract from the many strengths that D has (in comparison
with C++ et al.) The answer is always D has GC, it's
On Thursday, 17 July 2014 at 13:30:15 UTC, currysoup wrote:
On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
*According to Don Clugston's talk the default GC can pause for
~250ms which is totally insane for any kind of interactive or
near-real-time system. If their concurrent version
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
If D came without GC, it would have replaced C++ a long time
ago!
That's overly optimistic I think, but I believe that the adoption
rate would have been far greater for a D without GC, or perhaps
with a more GC friendly design, as the GC
I feel it is a major concern, if I'm starting a project with
low latency requirements* I certainly think twice about using
D. I think this could apply especially to people outside the
community who might not have experienced the benefits D
provides. The issue is not there is a GC, it's that
On Thursday, 17 July 2014 at 14:05:02 UTC, Brian Rogoff wrote:
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
If D came without GC, it would have replaced C++ a long time
ago!
That's overly optimistic I think, but I believe that the
adoption rate would have been far greater for a D
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
It's not about acceptance, it's about the reality that a GC
is not a universal solution to memory management.
Just from watching a few of the DConf 2014 talks, if you want
On Thursday, 17 July 2014 at 15:19:59 UTC, bachmeier wrote:
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
It's not about acceptance, it's about the reality that a GC
is not a universal solution to memory management.
Just
On 7/17/14, 2:57 AM, currysoup wrote:
On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
Digitalmars-d wrote:
It appears still to be a general meme that performance required no GC
and GC mean poor performance. The debate has
On Thursday, 17 July 2014 at 12:37:10 UTC, w0rp wrote:
For improving the GC to an acceptable level, I believe
collection only needs to execute fast enough such that it will
fit within a frame comfortably. So for something rendering at
60FPS you have 1 second / 60 frames ~= 16.6 milliseconds
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
snip
If D came without GC, it would have replaced C++ a long time
ago!
Agree +1000.
If GC is so good, why not make it an option, have a base lib w/o
GC.
If I want GC, I got me JRE. It seems that some in D want to write
a better JRE,
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
If GC is so good, why not make it an option, have a base lib
w/o GC.
Much of Phobos already is GC free. The parts that aren't should
be easy to convert to use user-supplied buffers. Please add
enhancement requests for cases where there
Vic:
If D came without GC, it would have replaced C++ a long time
ago!
Agree +1000.
I see no proof of this. And not everybody hates GCs.
Bye,
bearophile
On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander wrote:
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
If GC is so good, why not make it an option, have a base lib
w/o GC.
Much of Phobos already is GC free. The parts that aren't should
be easy to convert to use user-supplied
I hate GC, so there.
I see no proof of this. And not everybody hates GCs.
Bye,
bearophile
On Thursday, 17 July 2014 at 13:02:22 UTC, Remo wrote:
snip
The quality of GC implementation is probably more important.
I disagree, I am a burn victim and don't trust smoke.
Ideally it is optional.
Cheers,
Vic
On Thu, Jul 17, 2014 at 05:32:36PM +, Right via Digitalmars-d wrote:
I hate GC, so there.
I see no proof of this. And not everybody hates GCs.
[...]
I don't, so here. :D
T
--
I see that you JS got Bach.
On Thu, Jul 17, 2014 at 05:28:01PM +, Vic via Digitalmars-d wrote:
On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander wrote:
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
If GC is so good, why not make it an option, have a base lib w/o GC.
Much of Phobos already is GC
On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jul 17, 2014 at 05:28:01PM +, Vic via Digitalmars-d
wrote:
On Thursday, 17 July 2014 at 17:13:04 UTC, Peter Alexander
wrote:
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
If GC is so good, why
On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
That's good news! See, we're getting there, just bear with us.
This begs the question of course, how will this affect existing
code? My code is string intensive.
Usually GC-free API is added by providing new overloads that take
an
On Thursday, 17 July 2014 at 18:08:18 UTC, Dicebot wrote:
On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
That's good news! See, we're getting there, just bear with us.
This begs the question of course, how will this affect
existing code? My code is string intensive.
Usually GC-free
On Thursday, 17 July 2014 at 17:28:02 UTC, Vic wrote:
If that is true, I may even do a $ bounty to make Phobos GC
free.
Unless you do some hard real-time barebone stuff it is quite
likely you can do with limited usage of GC. Hiring some of
experienced D user to make a one-time case study
On 7/17/14, 2:32 PM, Right wrote:
I hate GC, so there.
I see no proof of this. And not everybody hates GCs.
Bye,
bearophile
Java is everywhere and it has a GC. Go is starting to be everywhere and
it has a GC. C# too has a GC, and I think they use it to make games too.
I don't think
On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
snip
If D came without GC, it would have replaced C++ a long time
ago!
Agree +1000.
If GC is so good, why not make it an option, have a base lib
w/o GC.
If I want GC, I got me
On Thu, Jul 17, 2014 at 05:58:14PM +, Chris via Digitalmars-d wrote:
On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via Digitalmars-d
wrote:
[...]
AFAIK some work still needs to be done with std.string; Walter for
one has started some work to implement range-based equivalents for
On Thu, Jul 17, 2014 at 06:09:49PM +, deadalnix via Digitalmars-d wrote:
On Thursday, 17 July 2014 at 18:08:18 UTC, Dicebot wrote:
On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
That's good news! See, we're getting there, just bear with us. This
begs the question of course, how
H. S. Teoh:
I don't think it will affect existing code (esp. given Walter's
stance on breaking changes!).
Making various parts of Phobos GC-free doesn't mean that nothing
GC-allocates, it means that Phobos will offer means to use memory
provided by the user. There are many situations where
On Thursday, 17 July 2014 at 18:22:11 UTC, H. S. Teoh via
Digitalmars-d wrote:
Actually, I've realized that output ranges are really only
useful when
you want to store the final result. For data in mid-processing,
you
really want to be exporting an input (or higher) range interface
instead,
On Thu, 2014-07-17 at 15:11 -0300, Ary Borenszweig via Digitalmars-d
wrote:
[…]
Java is everywhere and it has a GC. Go is starting to be everywhere and
it has a GC. C# too has a GC, and I think they use it to make games too.
I don't think everyone hates GCs. :-)
I think we need to try and
On 7/17/14, 11:11 AM, Ary Borenszweig wrote:
On 7/17/14, 2:32 PM, Right wrote:
I hate GC, so there.
I see no proof of this. And not everybody hates GCs.
Bye,
bearophile
Java is everywhere and it has a GC. Go is starting to be everywhere and
it has a GC. C# too has a GC, and I think
On Thursday, 17 July 2014 at 17:36:36 UTC, Vic wrote:
On Thursday, 17 July 2014 at 13:02:22 UTC, Remo wrote:
snip
The quality of GC implementation is probably more important.
I disagree, I am a burn victim and don't trust smoke.
Well it appears to be very hard to make proper GC.
So all the
I'm rather fond of RAII, I find that I rarely every need shared
semantics.
I use a custom object model that allows for weak_ptrs to
unique_ptrs which I think removes some cases where people might
otherwise be inclined to use shared_ptr.
Shared semantics are so rare in fact I would say I
On 7/17/14, 3:55 PM, Andrei Alexandrescu wrote:
On 7/17/14, 11:11 AM, Ary Borenszweig wrote:
On 7/17/14, 2:32 PM, Right wrote:
I hate GC, so there.
I see no proof of this. And not everybody hates GCs.
Bye,
bearophile
Java is everywhere and it has a GC. Go is starting to be everywhere
On 7/17/14, 12:26 PM, Ary Borenszweig wrote:
On 7/17/14, 3:55 PM, Andrei Alexandrescu wrote:
On 7/17/14, 11:11 AM, Ary Borenszweig wrote:
On 7/17/14, 2:32 PM, Right wrote:
I hate GC, so there.
I see no proof of this. And not everybody hates GCs.
Bye,
bearophile
Java is everywhere and
On Thursday, 17 July 2014 at 19:14:06 UTC, Right wrote:
I'm rather fond of RAII, I find that I rarely every need
shared semantics.
I use a custom object model that allows for weak_ptrs to
unique_ptrs which I think removes some cases where people might
otherwise be inclined to use shared_ptr.
On Thursday, 17 July 2014 at 12:37:10 UTC, w0rp wrote:
The key to making D's GC acceptable lies in two factors I
believe.
1. Improve the implementation enough so that you will only be
impacted by GC in extermely low memory or real time
environments.
2. Defer allocation more and more by using
On Thursday, 17 July 2014 at 22:06:01 UTC, Brad Anderson wrote:
I agreed with this for awhile but following the conversation
here
https://github.com/D-Programming-Language/phobos/pull/2149
I'm more inclined to think we should be adding lazy versions of
functions where possible rather than
On Thursday, 17 July 2014 at 22:16:10 UTC, Dicebot wrote:
On Thursday, 17 July 2014 at 22:06:01 UTC, Brad Anderson wrote:
I agreed with this for awhile but following the conversation
here
https://github.com/D-Programming-Language/phobos/pull/2149
I'm more inclined to think we should be adding
On Thursday, 17 July 2014 at 22:21:54 UTC, Brad Anderson wrote:
Well the idea is that you then copy into an output range with
whatever allocation strategy you want at the end. There is
quite a bit of overlap I think. Not complete overlap and
OutputRange accepting functions will still be needed
UE4 wasn't really rewritten from scratch, was more like, take
UE3, rewrite various parts and add new features, keep doing that
for a few years--
Code style isn't modern C++.
No lambda, r-value refs, unique types, algorithms(everyone just
bangs out for loops), task implementation is
On Thursday, 17 July 2014 at 22:27:52 UTC, Dicebot wrote:
On Thursday, 17 July 2014 at 22:21:54 UTC, Brad Anderson wrote:
Well the idea is that you then copy into an output range with
whatever allocation strategy you want at the end. There is
quite a bit of overlap I think. Not complete
1 - 100 of 106 matches
Mail list logo
