On 2014-09-21 07:55, Cliff wrote:

> Swift will never be more important than Objective C was - which is to
> say it'll be the main development language on Apple products and
> probably nothing else.  That has real value, but the limits on it are
> pretty hard and fast (which says more about Apple than the language
> itself.)
>
> .NET suffers a similar problem in spite of the community's best efforts
> with Mono - it'll always be a distant 2nd (or 5th or 20th) on other
> platforms.  And on Windows, C++ won't get supplanted by .NET absent a
> sea-change in the mindset of the Windows OS group - which is notoriously
> resistant to change (and they have a colossal existing code base which
> isn't likely to benefit from the kind of inflection point Apple had
> moving to a BSD and porting/rewriting scads of code.)

Unfortunately the user base is so large on these platforms that it's enough for these languages to only work on one particular platform and the developers will invest a huge amount work on it anyway. The languages will have a large user base even though they only work on one platform.

-- 
/Jacob Carlborg

On 2014-09-21 07:55, Cliff wrote:

> .NET suffers a similar problem in spite of the community's best efforts
> with Mono - it'll always be a distant 2nd (or 5th or 20th) on other
> platforms.  And on Windows, C++ won't get supplanted by .NET absent a
> sea-change in the mindset of the Windows OS group - which is notoriously
> resistant to change (and they have a colossal existing code base which
> isn't likely to benefit from the kind of inflection point Apple had
> moving to a BSD and porting/rewriting scads of code.)

Actually, Microsoft, with the help of Xamarin seems to aim for cross-paltform with Mono, at least for mobile platforms.

-- 
/Jacob Carlborg

On 2014-09-20 18:31, Adam D. Ruppe wrote:
> On Saturday, 20 September 2014 at 16:15:45 UTC, Andrei Alexandrescu wrote:
>> We need to explore that. A possibility is to support coexistence and
>> then have the option to use a tool statically pinpoint the uses of GC.
>> -- Andrei
>
> What, *exactly*, does "uses of GC" mean? In other words, what
> specifically makes GC.malloc evil that must be avoided at any cost while
> C malloc (+ GC.addRange most likely) is an acceptable replacement?
>
> A few things that come to mind are:
>
> 1) Obviously, GC.malloc can trigger a collection. But this can be easily
> disabled.
>
> 2) The GC lock? I don't know how malloc handles this though.
>
> 3) Is GC.free substantially different than C's free?
>
> 4) Programmers don't typically explicitly free GC memory... but we could.
>
> 5) Bookkeeping overhead? I know malloc has some too though, is this
> really a dealbreaker?
>
> 6) Public relations.
>
> ...that's all I can think of. What am I missing? Which one of these is
> actually causing the problem that we're supposed to be fixing here?

I think it's mostly 1) and then on second place 2).

-- 
/Jacob Carlborg

On 2014-09-20 18:53, Paulo Pinto wrote:

> I would say ARC == RC. I never saw a distinction in literature between
> both, before Apple used the term.

I never saw the term ARC before Apple used it. I would say, ARC is a form of RC but RC doesn't not need imply ARC. BTW "Automatic Reference Counting" on Wikipedia [1] basically only talks about Apple's ARC.

[1] http://en.wikipedia.org/wiki/Automatic_Reference_Counting

-- 
/Jacob Carlborg

On 2014-09-20 18:56, Andrei Alexandrescu wrote:

> Please don't take me in a court of law. But yes, I am talking about the
> compiler inserting calls to increment and decrement reference counts. --
> Andrei

We do need to know what you're proposal is for. How else can we comment on it? Paulo Pinto's comment "It requires compiler support, though" suggests, at least to me, he didn't understand you suggested ARC, i.e. RC with compiler support.

-- 
/Jacob Carlborg

Am Sat, 20 Sep 2014 09:07:20 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 9/20/14, 12:46 AM, Olivier Pisano wrote:
> > If making the GC completely optional is a must, then error handling shouldn't rely on it at all, no? What about completely switching exception handling to RC ? Would it have an impact on memory safety since exeption handling mecanism is somehow "magical code generated by the compiler" ?
> 
> The more I think of it the more sensible this is. Exceptions are unlikely to create cycles, not copied extensively, and are generally short lived. So an RC scheme backed by malloc/free seems to be most appropriate.
> 
> There would be breakage, though: Throwable would not be convertible to Object. I wonder what the impact in the real world that would cause.
> 
> 
> Andrei
> 

+1, replace it completely with malloc/free.

However, for backwards compatibility malloced exceptions probably still have to be added as roots to the GC, at least if they refer GC allocated data. This should be somehow optional however.

Am Sat, 20 Sep 2014 10:17:06 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 9/20/14, 9:31 AM, Adam D. Ruppe wrote:
> > On Saturday, 20 September 2014 at 16:15:45 UTC, Andrei Alexandrescu wrote:
> >> We need to explore that. A possibility is to support coexistence and then have the option to use a tool statically pinpoint the uses of GC. -- Andrei
> >
> > What, *exactly*, does "uses of GC" mean? In other words, what specifically makes GC.malloc evil that must be avoided at any cost while C malloc (+ GC.addRange most likely) is an acceptable replacement?
> >
> > A few things that come to mind are:
> >
> > 1) Obviously, GC.malloc can trigger a collection. But this can be easily disabled.
> >
> > 2) The GC lock? I don't know how malloc handles this though.
> >
> > 3) Is GC.free substantially different than C's free?
> >
> > 4) Programmers don't typically explicitly free GC memory... but we could.
> >
> > 5) Bookkeeping overhead? I know malloc has some too though, is this really a dealbreaker?
> >
> > 6) Public relations.
> >
> > ....that's all I can think of. What am I missing? Which one of these is actually causing the problem that we're supposed to be fixing here?
> 
> The only problem is that GC.malloc doesn't need to be paired by a call to GC.free, whereas malloc must.
> 
> Andrei
> 

You're both missing another obvious point:

7) The GC needs to be implemented in D, in the druntime. Malloc is
   available everywhere. The GC keeps a separate heap IIRC which wastes
   memory if you mix D code and C code which uses malloc. Both are
   important points for embedded systems. A druntime without GC is
   much easier to port and produces smaller binaries.

of course in that case, GC.addRange is not an acceptable replacement. Here 'use of GC' literally means use of GC ;-)

On Sunday, 21 September 2014 at 09:01:45 UTC, Johannes Pfau wrote:
> +1, replace it completely with malloc/free.
>
> However, for backwards compatibility malloced exceptions probably still
> have to be added as roots to the GC, at least if they refer GC
> allocated data. This should be somehow optional however.

Yeah, so the GC do not scan in it, and the error message disappear randomly under your feet and you segfault when trying to read. Looks like a great idea.

Am Sun, 21 Sep 2014 09:35:40 +0000
schrieb "deadalnix" <deadalnix@gmail.com>:

> On Sunday, 21 September 2014 at 09:01:45 UTC, Johannes Pfau wrote:
> > +1, replace it completely with malloc/free.
> >
> > However, for backwards compatibility malloced exceptions
> > probably still
> > have to be added as roots to the GC, at least if they refer GC
> > allocated data. This should be somehow optional however.
> 
> Yeah, so the GC do not scan in it, and the error message disappear randomly under your feet and you segfault when trying to read. Looks like a great idea.

If you always need to add exceptions to GC roots the whole proposal of reference counting exceptions is useless as you depend on the GC exactly in the same way as if you allocate from the GC. Andrei initially proposed pure reference-counted exceptions in -nogc which would suffer from the same issue.

And storing GC-allocated messages in exceptions is in most cases bad
design. If the message is a string literal there's no GC involved and
if you add 'information' to the message, making it dynamic, then:
* In order to process that information you need to extract it from the
  message string
* You create a dynamic string which might never be used (exception can
  be caught and ignored, etc.)

The correct design is to add the information to a variable in a subclassed exception and produce the message in toString, which can work entirely without a GC.

Example:
BAD:
throw new Exception("Timout occured, timeout = " ~
to!string(timeout))
GOOD: throw new TimeoutException("Timeout occured", timout)

Am 21.09.2014 10:51, schrieb Jacob Carlborg:
> On 2014-09-20 18:56, Andrei Alexandrescu wrote:
>
>> Please don't take me in a court of law. But yes, I am talking about the
>> compiler inserting calls to increment and decrement reference counts. --
>> Andrei
>
> We do need to know what you're proposal is for. How else can we comment
> on it? Paulo Pinto's comment "It requires compiler support, though"
> suggests, at least to me, he didn't understand you suggested ARC, i.e.
> RC with compiler support.
>

Sorry but I guess I did understand it. There are only four ways of doing RC, regardless how you name them.

- programmer writes manually calls to increment/decrement counters, like old time Cocoa and COM

- library types which take advantage of operator overloading for increment/decrement operations, like *_ptr<>(), ComPtr<>() and RefCounted

- automatic increment/decrement operations via special type or code pattern recognition => compiler support like Swift, Objective-C, C++/CLI, C++/CLX, Swift, Cedar, Modula-2+

- automatic increment/decrement operations via special type or code pattern recognition, followed by code removal of needless call pairs =>
compiler support like Objective-C and Swift

So given Andrei's comment, compiler support is required.

The only thing that distinguishes Apple solution from other ones, is that they made a marketing name for a common RC optimization.

--
Paulo