On Sunday, 4 May 2014 at 18:11:45 UTC, yazd wrote:
> On Friday, 2 May 2014 at 15:25:55 UTC, Nordlöw wrote:
>> On Friday, 2 May 2014 at 10:42:40 UTC, yazd wrote:
>>> On Thursday, 1 May 2014 at 17:31:52 UTC, Nordlöw wrote:
>>>>> Here you go, https://github.com/yazd/elf-d.
>>>>
>>>> Thanks!
>>>
>>> Anytime. By the way, if you need more stuff out of it or help, post an issue on github. I think I'll be able to help a bit more. But if this library is to move forward, the API will need a redesign. You might want to keep that in mind.
>>
>> Ok. Great!
>>
>> Some reflections:
>>
>> - This is not a robust way of detecting limitations of the package (elf.d):
>>
>>    static assert(is(size_t == ulong), "only 64bit is supported for now");
>>
>> This static assert needs to be called at run-time on the header contents of the mmapped file itself.
>>
>> - It is nice that you use MMFile. I do that too in my engine. However, to make cooperation more flexible and efficient class ELF should provide a ctor that takes and existing MMfile as argument (refernce) during construction, since my file engine class RegFile temporarily creates such instances when neeeded. BTW: What does package keyword mean in the line
>>
>>  package MmFile file;
>> inside the definition of ELF.
>>
>> For detail see for example:
>>
>> https://github.com/nordlow/justd/blob/master/fs.d#L1192
>
> You're correct in terms of the check. Anyway, I have just pushed some changes to support both 32bit and 64bit elf binary files. That required minor changes in the API, but it should still be easy.
> And I've added a constructor that takes an MmFile.
>
> `package` here is a protection attribute. From the documentation on dlang.org, " Package extends private so that package members can be accessed from code in other modules that are in the same package. This applies to the innermost package only, if a module is in nested packages."

Ok. Thx!

On Sunday, 4 May 2014 at 18:11:45 UTC, yazd wrote:
> On Friday, 2 May 2014 at 15:25:55 UTC, Nordlöw wrote:
>> On Friday, 2 May 2014 at 10:42:40 UTC, yazd wrote:
>>> On Thursday, 1 May 2014 at 17:31:52 UTC, Nordlöw wrote:
>>>>> Here you go, https://github.com/yazd/elf-d.
>>>>
>>>> Thanks!
>>>
>>> Anytime. By the way, if you need more stuff out of it or help, post an issue on github. I think I'll be able to help a bit more. But if this library is to move forward, the API will need a redesign. You might want to keep that in mind.
>>
>> Ok. Great!
>>
>> Some reflections:
>>
>> - This is not a robust way of detecting limitations of the package (elf.d):
>>
>>    static assert(is(size_t == ulong), "only 64bit is supported for now");
>>
>> This static assert needs to be called at run-time on the header contents of the mmapped file itself.
>>
>> - It is nice that you use MMFile. I do that too in my engine. However, to make cooperation more flexible and efficient class ELF should provide a ctor that takes and existing MMfile as argument (refernce) during construction, since my file engine class RegFile temporarily creates such instances when neeeded. BTW: What does package keyword mean in the line
>>
>>  package MmFile file;
>> inside the definition of ELF.
>>
>> For detail see for example:
>>
>> https://github.com/nordlow/justd/blob/master/fs.d#L1192
>
> You're correct in terms of the check. Anyway, I have just pushed some changes to support both 32bit and 64bit elf binary files. That required minor changes in the API, but it should still be easy.
> And I've added a constructor that takes an MmFile.
>
> `package` here is a protection attribute. From the documentation on dlang.org, " Package extends private so that package members can be accessed from code in other modules that are in the same package. This applies to the innermost package only, if a module is in nested packages."

Great work!

One thing though: You cannot call a filename the same as a keyword: package.d because

import elf.package;

fails with

fs.d(144,12): Error: identifier expected following package

Thx for the other fixes.

On 5/5/2014 8:17 PM, "Nordlöw" wrote:
>
>
> One thing though: You cannot call a filename the same as a keyword:
> package.d because
>
> import elf.package;
>
> fails with
>
> fs.d(144,12): Error: identifier expected following package
>

Actually, package.d is a feature which was added not so long ago. Given:

- foo
-- bar.d
-- baz.d
-- package.d

Where package.d looks like:

module foo.package;
public import foo.bar, foo.baz;

In client code, you can do this:

import foo;

And all of foo.bar and foo.baz will be visible. But you are correct that one cannot explicitly import 'foo.package'

On Monday, 5 May 2014 at 13:51:12 UTC, Mike Parker wrote:
> On 5/5/2014 8:17 PM, "Nordlöw" wrote:
>>
>>
>> One thing though: You cannot call a filename the same as a keyword:
>> package.d because
>>
>> import elf.package;
>>
>> fails with
>>
>> fs.d(144,12): Error: identifier expected following package
>>
>
> Actually, package.d is a feature which was added not so long ago. Given:
>
> - foo
> -- bar.d
> -- baz.d
> -- package.d
>
> Where package.d looks like:
>
> module foo.package;
> public import foo.bar, foo.baz;
>
> In client code, you can do this:
>
> import foo;
>
> And all of foo.bar and foo.baz will be visible. But you are correct that one cannot explicitly import 'foo.package'

Aha!

Thx