View mode: basic / threaded / horizontal-split · Log in · Help
December 13, 2011
Re: If I had my way
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/
December 13, 2011
Re: If I had my way
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
December 13, 2011
Re: If I had my way
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/
December 13, 2011
Re: If I had my way
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
December 13, 2011
Re: If I had my way
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
December 13, 2011
Re: If I had my way
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.
December 13, 2011
Re: If I had my way
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.
December 13, 2011
Re: If I had my way
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
December 13, 2011
Re: If I had my way
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
December 13, 2011
Re: If I had my way
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/
7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home