On Monday, 8 September 2014 at 16:56:49 UTC, Andrei Alexandrescu
wrote:
FWIW we could do this for backward compatibility: objects
without @monitor use the hashtable, and those with @monitor use
a field.
And that's exactly what current PR suggests. However, it's
stalled due to another issue. Th
IMHO LDC problems would be addressed much faster, if it
officially becomes the "reference" D compiler. LLVM would also
benefit from another community using it. So those unhappy with
LLVM's performance could also contribute (don't smile here! =) to
LLVM.
On Thursday, 22 May 2014 at 06:48:17 UTC, Martin Nowak wrote:
I don't see why we need to introduce a global hashtable
(performance impact, not pure). We could warn/deprecate/remove
synchronizing on classes without the @monitor attribute.
It's not only about synchronization. Signals use monitors
On Sunday, 18 May 2014 at 19:57:34 UTC, Walter Bright wrote:
The "_monitor" slot is also used for std.signals. It's been set
up in druntime to support more than just being a monitor.
We've also considered it for a hook for a reference count
(though that design had other problems).
I'm not sa
On Sunday, 18 May 2014 at 05:01:21 UTC, Walter Bright wrote:
While I agree with Andrei's agreements (!), the rationale for
the current approach is to make it relatively straightforward
to translate existing Java code into D. There was a fair amount
of this in the early days of D, I'm not sure h
On Sunday, 18 May 2014 at 04:44:56 UTC, Martin Nowak wrote:
Global hashmap is a bad idea IMO because it's possibly
expensive and impure. Rather deprecate synchronizing on classes
without an explicit monitor.
Totally agreed. Hashmap is done just not to break existing code.
I don't think i've got
On Wednesday, 14 May 2014 at 19:08:30 UTC, bearophile wrote:
You are good. Before this is ready for Walter's judgement I
think this needs some simple performance/memory benchmarks, to
compare the situation before and after this change.
I've made some minor optimizations, and rebased everything o
On Wednesday, 14 May 2014 at 14:44:07 UTC, Marc Schütz wrote:
The object's layout and size also change, but the layout of
objects is implementation defined AFAIK, and its size shouldn't
be hard-coded anyway, so the breakage is minimal.
You're right. Shared libraries will need to be rebuilt.
Me
On Wednesday, 14 May 2014 at 13:53:51 UTC, Damian Day wrote:
These would be breaking changes. I see the benefit but...
Breaking, only if someone used to define __monitor in his class.
Which is kinda weird, and according to docs (identifiers starting
with __ should are reserved). Or if someone u
On Wednesday, 14 May 2014 at 13:07:32 UTC, bearophile wrote:
I'd like to know why you think D classes should not have the
monitor on default (this means why you don't plan for a
@no_pointer).
There are 4 reasons for that.
1. I'm thinking of monitors as members of Object class, so all
other cla
On Wednesday, 14 May 2014 at 11:14:47 UTC, bearophile wrote:
I suggest a name like "@monitor". The is no need for the
underscores.
Done.
A more tidy design could require the @monitor in all classes
that inherit from a @monitor-annotated class. But this also
looks a little overkill. So let's h
bearophile, good point. What do you think of the following
solution:
1. Declaring member variable with __monitor identifier is
disallowed.
2. class may be defined with @__monitor attribute, in which case
a __monitor variable will be added to it's beginning.
3. Subclass of such class may again be
On Wednesday, 14 May 2014 at 08:37:41 UTC, bearophile wrote:
What's the syntax to define a class without its __monitor? Are
you using an annotation like @no_monitor?
No syntax for that. The __monitor is not present by default
anywhere. If you need it, you need to define one.
class A
{
}
clas
Ok, i think i've found a simple yet effective solution.
Implemented and pushed to the repo. Any more thoughts before a PR?
The only downside i see here is that finalization of every
object will now lookup for a corresponding monitor, if it's
class doesn't define embedded one.
Ok, i think i've found a simple yet effective solution.
Adding a flag to ClassFlags: hasAllocatedMonitors.
Mark m_flags with this flag in run
Hello, I've played a bit with monitors, trying to make them
optional, and here's what i've come up with:
https://github.com/yglukhov/dmd/tree/optional_monitor
https://github.com/yglukhov/druntime/tree/optional_monitors
The whole idea is that Object doesn't contain __monitor field
anymore.
TypeI
Adam, that doesn't seem to work for me:
import std.typetuple;
import std.string;
import std.stdio;
template isImport(string i)
{
static if (__traits(compiles, mixin(i).stringof) &&
mixin(i).stringof.startsWith("module "))
enum isImport = true;
else
enum isImport = false;
Hello D community,
What do you think of a new __traits(getImports, Scope), that
returns a tuple of strings, which are imports made in a scope? If
scope is a module, it will produce a tuple like ("std.conv",
"std.traits").
rtInfo through attributes implemented. Jacob, have i done it the
way you wanted?
https://github.com/D-Programming-Language/druntime/pull/775#issuecomment-41278520
Also, this whole thing is not only about RT registration, it may
be used differently. The next usage that comes to mind after RT
is validating proper inheritance. E.g. Some root class wants it's
subclasses to always have a default ctor available, which again
can be verified in CT.
I guess this could be done without modifying the compiler, just
extend RTInfo(T) to support this UDA, but there's a problem
with attributes. They don't propagate to class' children, thus
they can't solve the main question of this topic.
But as an additional feature such UDA might be useful.
On Thursday, 24 April 2014 at 06:08:11 UTC, Jacob Carlborg wrote:
On 24/04/14 00:29, Martin Nowak wrote:
Looks fairly interesting, because it partly solves the issue
to allow
custom rtinfo.
I don't like this solution for custom RTInfo. It requires you
to change your type. I would rather mod
Ok, i've added a pull request to be discussed. It expands RTInfo
capability as Jacob suggested. What do you think?
https://github.com/D-Programming-Language/druntime/pull/775
Any way to do it without patching druntime?
Hello, is there a way of getting CT info of a class' children?
If no, what do you think of a new feature for DMD: template this
static ctors/dtors:
class A
{
static this(this T)()
{
writeln("static this(", T.stringof, ")");
}
}
class B : A
{
}
would output:
static this(A
25 matches
Mail list logo
