On 4/6/2017 6:00 AM, Shachar Shemesh wrote:
The preallocated exceptions in weka were created as a work around for exceptions
requiring GC. If we can throw without invoking the GC, we'll probably be fine
with tossing them.
Shachar
That's what I thought. Thanks for the confirmation.
On Monday, 3 April 2017 at 21:43:13 UTC, Adam D. Ruppe wrote:
This file shows like 3 concepts I have with exceptions, but the
RaisedExceptionDetails.toString shows this:
http://arsdnet.net/exception.d
It is an easily solved library problem... and would be *easier*
to use than format().
I
On 02/04/17 18:24, Dmitry Olshansky wrote:
On 4/2/17 9:14 AM, Walter Bright wrote:
On 4/1/2017 11:50 PM, Nicholas Wilson wrote:
On Sunday, 2 April 2017 at 05:16:23 UTC, Walter Bright wrote:
Problem
===
[...]
How will this interact with preallocated exceptions (e.g. from
Liran's dconf
t
On Wednesday, 5 April 2017 at 17:35:01 UTC, Jack Stouffer wrote:
Suggested party line: if you don't want to use druntime, best
of luck, you're on your own. We're not going to gimp Phobos for
you.
s/wan't/can't
Avoiding druntime is not done for the fun of it, but because
there is (in rare ca
On Wednesday, 5 April 2017 at 16:33:42 UTC, Guillaume Piolat
wrote:
This means TLS is here but uninitialized and eg. core.cpuid has
to be duplicated.
Fragmentation ensues.
Good, it provides options with various tradeoffs that fulfill
more needs. If you don't want to have choice, use stock
dr
On Monday, 3 April 2017 at 23:33:10 UTC, Jack Stouffer wrote:
Example: company wants to use their custom GC (like
sociomantic) with Phobos. They want to do this even for
exceptions because they believe that things will be faster if
they're able to completely control when any memory is freed.
Y
On Wednesday, 5 April 2017 at 09:51:16 UTC, Walter Bright wrote:
Much of Phobos has been redone to not assume/require the GC. A
glaring exception (!) is when Exceptions are thrown, which is
why we're looking for a solution.
Make the exception owned, and let the caller decide.
On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat
wrote:
But those of us with the runtime disabled don't have TLS.
throwing, .destroy, TLS (and static this) are the fragmenting
factors between runtime-free and D normal D.
I'm going to be harsh here and say that the D team members sh
On Wednesday, 5 April 2017 at 16:33:42 UTC, Guillaume Piolat
wrote:
This means TLS is here but uninitialized and eg. core.cpuid has
to be duplicated.
Fragmentation ensues.
You can still lazily initialise TLS data, though. — David
On Wednesday, 5 April 2017 at 16:08:33 UTC, David Nadlinger wrote:
On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat
wrote:
But those of us with the runtime disabled don't have TLS.
This is only true on DMD/OS X x86, where TLS is emulated in
druntime. On other platforms, TLS is imp
On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat
wrote:
But those of us with the runtime disabled don't have TLS.
This is only true on DMD/OS X x86, where TLS is emulated in
druntime. On other platforms, TLS is implemented by the linker
and/or C runtime, so it works without drunti
On Monday, 3 April 2017 at 22:30:46 UTC, Walter Bright wrote:
Using a singleton in TLS is indeed memory safe, as long as you
don't do things like keep a reference to it around and expect
it not to change.
But those of us with the runtime disabled don't have TLS.
throwing, .destroy, TLS (and
On Wednesday, 5 April 2017 at 09:51:16 UTC, Walter Bright wrote:
Much of Phobos has been redone to not assume/require the GC. A
glaring exception (!) is when Exceptions are thrown, which is
why we're looking for a solution.
Much, but not most. Dynamic arrays, AAs, closures, and all
classes ar
Much of Phobos has been redone to not assume/require the GC. A glaring exception
(!) is when Exceptions are thrown, which is why we're looking for a solution.
On 04/04/2017 04:08 AM, Atila Neves wrote:
I think the point here is that some people already use pre-allocated
exceptions. With this proposal, they'd have to change their codebase or
suddenly have it go much slower.
Isn't the main point of pre-allocated exceptions to improve
control/determi
On 4/4/2017 10:38 AM, Atila Neves wrote:
Right, but that doesn't mean the slow path should become all the more slower for
codebases that do this. I haven't, but if I had I'd imagine I'd be none too
happy about it.
A year ago or so, I switched the exception unwinding mechanism for D on Linux
fr
On Tuesday, 4 April 2017 at 08:41:51 UTC, Walter Bright wrote:
On 4/4/2017 1:08 AM, Atila Neves wrote:
I think the point here is that some people already use
pre-allocated exceptions.
With this proposal, they'd have to change their codebase or
suddenly have it go
much slower.
High performanc
On Monday, 3 April 2017 at 15:16:31 UTC, Jack Stouffer wrote:
On Monday, 3 April 2017 at 14:36:43 UTC, Kagamin wrote:
I suppose they link-hack GC, not druntime.
Nope, they get rid of everything, see
https://theartofmachinery.com/2016/12/18/d_without_runtime.html
That article is pretty caref
On Tuesday, 4 April 2017 at 00:45:08 UTC, Moritz Maxeiner wrote:
AFAICT this solution will end up with everyone always calling
theAllocator.dispose when catching from Phobos.
Yes, because you can no longer assume that the GC is being used,
as all current Phobos code does.
Here's the thing, t
On 4/3/2017 11:59 PM, Jonathan M Davis via Digitalmars-d wrote:
No, it's not a problem that's specific to exceptions, but the string for an
exception message is pretty critical and is going to have a significant
impact on the ability to use @nogc with exceptions. Just being able to have
the excep
On 4/4/2017 1:08 AM, Atila Neves wrote:
I think the point here is that some people already use pre-allocated exceptions.
With this proposal, they'd have to change their codebase or suddenly have it go
much slower.
High performance code should never have exceptions in the fast path. The code
ge
On Sunday, 2 April 2017 at 20:35:27 UTC, Walter Bright wrote:
On 4/2/2017 8:24 AM, Dmitry Olshansky wrote:
[...]
That's right.
[...]
Yes, it's possible. But I'd have to be convinced that there
isn't some other problem with a design that requires
preallocated exceptions.
[...]
I thin
On Monday, April 03, 2017 15:20:23 Walter Bright via Digitalmars-d wrote:
> On 4/3/2017 2:31 PM, Jonathan M Davis via Digitalmars-d wrote:
> > Yeah, the simple fact that you can't allocate exceptions in @nogc code
> > is
> > crippling to @nogc, and a lot of code that could otherwise be @nogc
> > ca
Am Mon, 03 Apr 2017 14:31:39 -0700
schrieb Jonathan M Davis via Digitalmars-d
:
> On Monday, April 03, 2017 14:00:53 Walter Bright via Digitalmars-d
> wrote:
> > The idea of this proposal is to make a nogc program much more
> > achievable. Currently, in order to not link with the GC, you can't
> >
On Monday, 3 April 2017 at 23:33:10 UTC, Jack Stouffer wrote:
On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
I don't see a point to having disparate allocation strategies
for exception objects.
Example: company wants to use their custom GC (like
sociomantic) with Phobos. They w
On Monday, 3 April 2017 at 22:20:23 UTC, Walter Bright wrote:
You're right that this proposal does not address how memory is
allocated for anything indirectly referenced by the exception
object. That is an independent issue, and is not peculiar to
exception objects.
There is no issue specific
On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
I don't see a point to having disparate allocation strategies
for exception objects.
Example: company wants to use their custom GC (like sociomantic)
with Phobos. They want to do this even for exceptions because
they believe that t
On 4/3/2017 2:38 PM, David Nadlinger wrote:
On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
The idea of this proposal is to make a nogc program much more achievable.
Currently, in order to not link with the GC, you can't use exceptions (or at
least not in a memory safe manner). A s
On 4/3/2017 2:31 PM, Jonathan M Davis via Digitalmars-d wrote:
Yeah, the simple fact that you can't allocate exceptions in @nogc code is
crippling to @nogc, and a lot of code that could otherwise be @nogc can't be
because of exceptions - though the exception message poses a similar problem
(espec
On Monday, 3 April 2017 at 21:31:39 UTC, Jonathan M Davis wrote:
though the exception message poses a similar problem
(especially if you'd normally construct it with format), and I
don't know how you get around that other than not using
anything more informative than string literals
This is w
On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
The idea of this proposal is to make a nogc program much more
achievable. Currently, in order to not link with the GC, you
can't use exceptions (or at least not in a memory safe manner).
A solution without memory safety is not accept
On Monday, April 03, 2017 14:00:53 Walter Bright via Digitalmars-d wrote:
> The idea of this proposal is to make a nogc program much more achievable.
> Currently, in order to not link with the GC, you can't use exceptions (or
> at least not in a memory safe manner). A solution without memory safety
On 4/3/2017 6:43 AM, Jack Stouffer wrote:
Sounds like using compiler magic for changing the behavior of existing syntax
rather than fixing the actual problem that std.allocators is trying to solve:
unifying disparate allocation strategies/needs across libraries.
I don't see a point to having di
On 4/3/2017 3:58 AM, Jerry wrote:
What would happen if the exception gets assigned to a global/TLS variable in a
catch block. It would be copied to the GC heap?
You'd have to insert code to manually make a clone of the exception object. The
compiler will complain if you try to leak the excepti
On Monday, 3 April 2017 at 14:36:43 UTC, Kagamin wrote:
I suppose they link-hack GC, not druntime.
Nope, they get rid of everything, see
https://theartofmachinery.com/2016/12/18/d_without_runtime.html
On Monday, 3 April 2017 at 14:27:47 UTC, Jack Stouffer wrote:
I don't know if you've been following some of the discussions
here and on Learn, but there are a couple of people now
link-hacking druntime completely out of their binaries in order
to avoid implicit GC calls and implicit copying.
On Monday, 3 April 2017 at 14:20:48 UTC, Kagamin wrote:
On Monday, 3 April 2017 at 13:43:35 UTC, Jack Stouffer wrote:
Also, half of the nogc purists aren't going to be using
druntime anyway.
druntime is not GC.
C++ uses quite sizable runtime >1mb.
I don't know if you've been following some o
On Monday, 3 April 2017 at 13:43:35 UTC, Jack Stouffer wrote:
Also, half of the nogc purists aren't going to be using
druntime anyway.
druntime is not GC.
C++ uses quite sizable runtime >1mb.
On Sunday, 2 April 2017 at 05:16:23 UTC, Walter Bright wrote:
then it is optimized to call 'allocate' instead.
Sounds like using compiler magic for changing the behavior of
existing syntax rather than fixing the actual problem that
std.allocators is trying to solve: unifying disparate allocat
What would happen if the exception gets assigned to a global/TLS
variable in a catch block. It would be copied to the GC heap?
On 4/2/2017 7:02 PM, crimaniak wrote:
On Sunday, 2 April 2017 at 05:16:23 UTC, Walter Bright wrote:
Using a ref counted solution brings with it a host of problems because
the compiler is not set up to ref count class object references, nor
is any existing code set up to deal with that.
Please d
On Sunday, 2 April 2017 at 05:16:23 UTC, Walter Bright wrote:
Using a ref counted solution brings with it a host of problems
because
the compiler is not set up to ref count class object
references, nor
is any existing code set up to deal with that.
Please describe in more detail the problems in
On 4/2/2017 8:24 AM, Dmitry Olshansky wrote:
Copy means allocate and then deallocate in the catch, defeating the whole
propose of preallocating.
That's right.
Would it be possible to just set a bit somewhere that
indicates that the exception is preallocated and need not be freed.
Yes, it's
On 4/2/17 9:14 AM, Walter Bright wrote:
On 4/1/2017 11:50 PM, Nicholas Wilson wrote:
On Sunday, 2 April 2017 at 05:16:23 UTC, Walter Bright wrote:
Problem
===
[...]
How will this interact with preallocated exceptions (e.g. from
Liran's dconf
talk last year)?
It will copy them and thro
On 4/1/2017 11:50 PM, Nicholas Wilson wrote:
On Sunday, 2 April 2017 at 05:16:23 UTC, Walter Bright wrote:
Problem
===
[...]
How will this interact with preallocated exceptions (e.g. from Liran's dconf
talk last year)?
It will copy them and throw the copy.
On Sunday, 2 April 2017 at 05:16:23 UTC, Walter Bright wrote:
Problem
===
[...]
How will this interact with preallocated exceptions (e.g. from
Liran's dconf talk last year)?
On 4/1/2017 10:29 PM, rikki cattermole wrote:
1) What if an exception dtor throws (yuck but eh)?
That's treated as a new exception.
2) Could this in some form be paired with allocators? e.g.
typeof(this) dup(IAllocator) { ... }
throw new MyException(8); versus throw alloc.make!MyException(8);
I should have noted that this does not involve any syntax changes.
On 02/04/2017 6:16 AM, Walter Bright wrote:
Problem
===
Exceptions are assumed to be GC collected by the EH design, in that no
attempt is made to control copies or lifetimes. This dependency is not
a performance issue, as exceptions are presumed to be slow.
The issue is it impairs use of @n
Problem
===
Exceptions are assumed to be GC collected by the EH design, in that no
attempt is made to control copies or lifetimes. This dependency is not
a performance issue, as exceptions are presumed to be slow.
The issue is it impairs use of @nogc on any code that throws exceptions,
and p
50 matches
Mail list logo
