On 2011-12-13 14:53:22 +0000, Jacob Carlborg <doob@me.com> said:

> In this callback I extract module infos, exception handling tables and TLS data from the mach_header. This is now where the problem comes. I need an associative array which maps mach_headers to a struct (or similar) containing module infos, exception handling tables and TLS data. But I don't have an associative array that works this earily in the initialization phase of the runtime.

Given this code is going to be specific to OS X, maybe you could use a CFMutableDictionary instead of rewriting your own hash table.

<http://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFMutableDictionaryRef/Reference/reference.html>

-- 


Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Tuesday, December 13, 2011 06:40:40 Michel Fortin wrote:
> On 2011-12-13 04:25:33 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:
> > For arrays, all you need to do is have the first argument be an array, and that works great for arrays, but arrays don't have much in the way of functions built in, so there's no conflict.
> 
> Actually, there's still an open issue with array-member syntax and @property used together.

How so? If it's a property function, not a member function (which couldn't use array-member syntaxt anyway), and it takes an array as its first argument, then it _must_ be called with array-member syntax without parens. If it isn't a property, then you could call it with or without array-member syntax, but you have to use parens. I don't see any conflict there.

Now, I don't know what -property is doing with it at the moment, but I don't see how it could work any other way.

- Jonathan M Davis

On 2011-12-13 16:57:33 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:

> On Tuesday, December 13, 2011 06:40:40 Michel Fortin wrote:
>> On 2011-12-13 04:25:33 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:
>>> For arrays, all you need to do is have the first argument be an array,
>>> and that works great for arrays, but arrays don't have much in the way
>>> of functions built in, so there's no conflict.
>> 
>> Actually, there's still an open issue with array-member syntax and
>> @property used together.
> 
> How so? If it's a property function, not a member function (which couldn't use
> array-member syntaxt anyway), and it takes an array as its first argument, then
> it _must_ be called with array-member syntax without parens. If it isn't a
> property, then you could call it with or without array-member syntax, but you
> have to use parens. I don't see any conflict there.

The problem is that the definition of an array-member property getter is the same thing as the definition of a module-level property setter.


> Now, I don't know what -property is doing with it at the moment, but I don't
> see how it could work any other way.

Currently I think you can do this:

	import std.range;

	int[] array = [1, 2];
	int x = array.front; // fine
	int y = (front = a); // ???

And also you can't define array-member property setters because they take three arguments and three argument property functions are not allowed.

And also, in case of conflict, currently you can write `std.range.front(array)` to disambiguate, but how does that work with @property enforcement, probably not that well?


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2011-12-13 17:57, Michel Fortin wrote:
> On 2011-12-13 14:53:22 +0000, Jacob Carlborg <doob@me.com> said:
>
>> In this callback I extract module infos, exception handling tables and
>> TLS data from the mach_header. This is now where the problem comes. I
>> need an associative array which maps mach_headers to a struct (or
>> similar) containing module infos, exception handling tables and TLS
>> data. But I don't have an associative array that works this earily in
>> the initialization phase of the runtime.
>
> Given this code is going to be specific to OS X, maybe you could use a
> CFMutableDictionary instead of rewriting your own hash table.
>
> <http://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFMutableDictionaryRef/Reference/reference.html>

That's a good idea, I didn't think about that. I often forget about the Mac specific API's.

I'm not sure, but we might need an associative array for the other platforms as well.

-- 
/Jacob Carlborg

On Tuesday, December 13, 2011 12:14:37 Michel Fortin wrote:
> On 2011-12-13 16:57:33 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:
> > On Tuesday, December 13, 2011 06:40:40 Michel Fortin wrote:
> >> On 2011-12-13 04:25:33 +0000, Jonathan M Davis <jmdavisProg@gmx.com>
said:
> >>> For arrays, all you need to do is have the first argument be an
> >>> array,
> >>> and that works great for arrays, but arrays don't have much in the
> >>> way
> >>> of functions built in, so there's no conflict.
> >> 
> >> Actually, there's still an open issue with array-member syntax and @property used together.
> > 
> > How so? If it's a property function, not a member function (which couldn't use array-member syntaxt anyway), and it takes an array as its first argument, then it _must_ be called with array-member syntax without parens. If it isn't a property, then you could call it with or without array-member syntax, but you have to use parens. I don't see any conflict there.
> 
> The problem is that the definition of an array-member property getter is the same thing as the definition of a module-level property setter.

I forgot about that, though I never liked the idea of module-level properties in the first place.

> > Now, I don't know what -property is doing with it at the moment, but I don't see how it could work any other way.
> 
> Currently I think you can do this:
> 
> import std.range;
> 
> int[] array = [1, 2];
> int x = array.front; // fine
> int y = (front = a); // ???
> 
> And also you can't define array-member property setters because they take three arguments and three argument property functions are not allowed.

You mean calling a property function on an element in an array? I would only have expected that to work if the element type had such a property. I wouldn't ever have expected you to be able to declare a property for arrays which allowed you to call it as a property on the array's elements.

> And also, in case of conflict, currently you can write `std.range.front(array)` to disambiguate, but how does that work with @property enforcement, probably not that well?

Disambiguate with what? With a module-level property? As it stands, I expect that module-level properties which are arrays just wouldn't work.

- Jonathan M Davis

On 12/13/2011 6:15 AM, Martin Nowak wrote:
> TLS is not too difficult. We can either use bracketed sections again or
> let the compiler emit small thunks that fetch the complete TLS section for
> a executable/DSO. The important point is that fetching the TLS addresses must
> be done for each thread and from a local function within each DSO.
> people.redhat.com/drepper/tls.pdf
> My current approach is to register callbacks, and let the threads update
> their ranges before GC.
> Not sure, but it will probably causes eagerly allocation of the TLS blocks.
>
> Some similar issues happen with the other section brackets (.deh, .minfo).
> We need local symbols as brackets not global ones as they would collide.
>
> I've tried several approaches.
>
> o Using a linker script with a recent binutils, add needed d sections
> and use PROVIDE_HIDDEN to bracket them. Then it's only a matter
> of adding constructor/destructor routines that register with druntime.
>
> It's not too feasible as newer binutils are default on linux only
> and distributing linker scripts is not too nice either.
>
> o Create a C module similar to crt0.o that creates d sections and bracketing
> symbols. Add constructor/destructor to register with druntime.
>
> The object file needs to be the first when linking, but the linker
> can merge sections, thus there is only one registration per
> executable/shared library.
>
> o Let the compiler generate a constructor/destructor for executables
> and shared libraries. The object would also need to get linked first.
>
> This is less transparent than the 2nd option without much benefit.
>
> o Generate registration routines per object file. No bracketed sections.

If the compiler generated static constructors and destructors ala C++ that would then be used to register the sections, that could hook into the existing C++ support code and not require special linker scripts and special object files.

On 12/13/2011 6:53 AM, Jacob Carlborg wrote:
> As you can see I don't have an associative array so the above currently doesn't
> work.

Just to get things off the ground, you could use a simple linear array.

On 12/13/11 10:45 AM, Hans Uhlig wrote:
> On 12/11/2011 11:32 AM, Andrei Alexandrescu wrote:
>> On 12/11/11 12:17 PM, Chad J wrote:
>>> On 12/11/2011 11:21 AM, Andrei Alexandrescu wrote:
>>>> On 12/11/11 9:14 AM, Chad J wrote:
>>>>>
>>>>> I think one thing that could would be (optional) reference counting
>>>>> for
>>>>> transitively atomic types. Of course, this is just another kind of
>>>>> garbage collection, but it is /deterministic/ and parallelizes well,
>>>>> and
>>>>> I bet this would open up a large amount of Phobos while the
>>>>> stop-the-world collector is offline, and with little or no code
>>>>> change.
>>>>
>>>> I think the language has enough (in theory) and nearly enough (in
>>>> practice) expressiveness to implement reference counted classes in a
>>>> library, virtually transparently. I mean one could define a template
>>>> RefCounted (an extended version of what's now in std) such that this
>>>> pattern is possible:
>>>>
>>>> // client code
>>>> class WidgetImpl {
>>>> ...
>>>> }
>>>>
>>>> alias RefCounted!WidgetImpl Widget;
>>>>
>>>> Aside from using WidgetImpl in type relationships, using Widget would
>>>> transparently insert the appropriate reference counting without
>>>> otherwise interfering with normal WidgetImpl semantics.
>>>>
>>>>
>>>> Andrei
>>>
>>> This is good. So stick it in the runtime and make the compiler emit
>>> RefCounted!___ templates whenever it finds a transitively atomic type.
>>>
>>> This can be done alongside the existing garbage collector.
>>>
>>> Then we can benchmark different combinations of memory management
>>> strategies.
>>>
>>> Two compiler flags can work in tandem:
>>> -nogc
>>> -norefcount
>>>
>>> (Turn them both off if you really want to break Phobos.)
>>
>> We considered that route, and concluded it's marred by too many issues.
>>
>> Andrei
>>
>
> What issues did it cause?

Inheritance, conversions, type checks, circular references, ...

Andrei

On 2011-12-13 20:17, Walter Bright wrote:
> On 12/13/2011 6:53 AM, Jacob Carlborg wrote:
>> As you can see I don't have an associative array so the above
>> currently doesn't
>> work.
>
> Just to get things off the ground, you could use a simple linear array.

Michel pointed me to the dictionary in the CoreServices framework I think I'll use that. But I still don't know how to access the current object/mach_header.

-- 
/Jacob Carlborg

On 2011-12-13 18:13:38 +0000, "Jonathan M Davis" <jmdavisProg@gmx.com> said:

> On Tuesday, December 13, 2011 12:14:37 Michel Fortin wrote:
>> On 2011-12-13 16:57:33 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:
>>> Now, I don't know what -property is doing with it at the moment, but I
>>> don't see how it could work any other way.
>> 
>> Currently I think you can do this:
>> 
>> import std.range;
>> 
>> int[] array = [1, 2];
>> int x = array.front; // fine
>> int y = (front = a); // ???
>> 
>> And also you can't define array-member property setters because they
>> take three arguments and three argument property functions are not
>> allowed.
> 
> You mean calling a property function on an element in an array? I would only
> have expected that to work if the element type had such a property. I wouldn't
> ever have expected you to be able to declare a property for arrays which
> allowed you to call it as a property on the array's elements.

Oops. That was a typo. I meant (front = array). "a" is undefined in the example above.


>> And also, in case of conflict, currently you can write
>> `std.range.front(array)` to disambiguate, but how does that work with
>> @property enforcement, probably not that well?
> 
> Disambiguate with what? With a module-level property? As it stands, I expect
> that module-level properties which are arrays just wouldn't work.

Say you have a array-member property called "front" defined in std.range (not hard to imagine) and an identical property called "front" in another module and you import both modules: "array.front" becomes ambiguous. With the function call syntax you can write std.range.front(array) and other.module.front(array) as a substitute to the property syntax to disambiguate, but if the property syntax is enforced should calling the property as a function still be allowed for array-member functions? Or should we invent a syntax such as array.(other.module.front)?

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/