On 5/4/12, foobar <foo@bar.com> wrote:
> How about augmenting the object format so that libraries would be self contained and would not require additional .di files? Is this possible optlink by e.g. adding special sections that would be otherwise ignored?

How would you use a library you don't even have the interface to? I mean if you can't even look at the API in your editor.. that'd be insane.

On 5/4/12, Trass3r <un@known.com> wrote:
>> I'm interested in starting a project to make a linker besides optlink for dmd on windows.
>
> Imho changing dmd to use COFF (incl. 64 support) instead of that crappy OMF would be more beneficial than yet another linker.

Hear hear.

But I wouldn't mind seeing a linker in D, just for research purposes.

On Friday, 4 May 2012 at 17:54:47 UTC, Andrej Mitrovic wrote:
> On 5/4/12, foobar <foo@bar.com> wrote:
>> How about augmenting the object format so that libraries would be
>> self contained and would not require additional .di files? Is
>> this possible optlink by e.g. adding special sections that would
>> be otherwise ignored?
>
> How would you use a library you don't even have the interface to? I
> mean if you can't even look at the API in your editor.. that'd be
> insane.

How about using the documentation? It's meant to be consumed by humans and comes with (or should if it isn't yet) with nicely formatted explanations.

The di files are mostly meant to be machine read (e.g. the compiler) and this belongs as part of the library file in order to provide ease of use and maintain the relationship between the binary code and it's interface.

maintaining two sets of files that could easily get out of sync and *not* using the docs is way more insane.

On Friday, 4 May 2012 at 17:52:54 UTC, simendsjo wrote:
> On Fri, 04 May 2012 18:57:44 +0200, foobar <foo@bar.com> wrote:
>
>> On Thursday, 3 May 2012 at 23:47:26 UTC, Trass3r wrote:
>>>> I'm interested in starting a project to make a linker besides optlink for dmd on windows.
>>>
>>> Imho changing dmd to use COFF (incl. 64 support) instead of that crappy OMF would be more beneficial than yet another linker.
>>>
>>>
>>>> My vision is to create a linker in a relatively modern language (D) and to release the project as open source.
>>>
>>> If you do write a linker then make it cross-platform right from the start; and modular so it can support all object file formats.
>>
>> How about augmenting the object format so that libraries would be self contained and would not require additional .di files? Is this possible optlink by e.g. adding special sections that would be otherwise ignored?
>>
>> I think that's what Go did in their linker but I don't know what format they use, if it's something specific to Go or general.
>>
>
> http://dsource.org/projects/ddl

This is D1 only and AFAIK was abandoned long ago.
Was a very good idea though and should be adopted by "official" D tool chain.

On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 5/4/12, foobar <foo@bar.com> wrote:
>> How about augmenting the object format so that libraries would be
>> self contained and would not require additional .di files? Is
>> this possible optlink by e.g. adding special sections that would
>> be otherwise ignored?
>
> How would you use a library you don't even have the interface to? I
> mean if you can't even look at the API in your editor.. that'd be
> insane.

Ever heard of Java?

-Steve

On 5/4/12, foobar <foo@bar.com> wrote:
> The di files are mostly meant to be machine read (e.g. the compiler) and this belongs as part of the library file in order to provide ease of use and maintain the relationship between the binary code and it's interface.
>
> maintaining two sets of files that could easily get out of sync and *not* using the docs is way more insane.
>

I'd say the docs are more likely to be out of sync than .di code. If the .di code is really out of sync you'll likely even get linker errors. And not everything ends up being documented.

And then what about existing tools like IDEs and editors. E.g. autocomplete wouldn't work anymore.

On 5/4/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> Ever heard of Java?

Ever heard of not requiring a bring-your-quadcore-to-its-knees IDE?

On Fri, 04 May 2012 14:31:24 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 5/4/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> Ever heard of Java?
>
> Ever heard of not requiring a bring-your-quadcore-to-its-knees IDE?

This is a totally false comparison :)  Java's storage of its interface in its object files has nothing to do with its IDE's performance.

What I'm saying is, it's completely possible to store the API in binary format *in* the object files, and use documentation generators to document the API.  You do not have to read the interface files to understand the API, and Java is a good example of a language that successfully does that.

-Steve

On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
> On 5/4/12, foobar <foo@bar.com> wrote:
>> The di files are mostly meant to be machine read (e.g. the
>> compiler) and this belongs as part of the library file in order
>> to provide ease of use and maintain the relationship between the
>> binary code and it's interface.
>>
>> maintaining two sets of files that could easily get out of sync
>> and *not* using the docs is way more insane.
>>
>
> I'd say the docs are more likely to be out of sync than .di code. If
> the .di code is really out of sync you'll likely even get linker
> errors. And not everything ends up being documented.
>
> And then what about existing tools like IDEs and editors. E.g.
> autocomplete wouldn't work anymore.

I'd say you'd be wrong.
Both di and docs are auto-generated from the same source.
As I said docs are designed for human consumption. This includes all sorts of features such as a table of contents, a symbol index, the symbols should have links, the docs provide usage examples, etc, etc.
Docs can be put online thus ensuring they're always up-to-date.

Tools should either read the data from the lib file or retrieve it from the web. Keeping separate local di files is simply insane.

And really, have you never heard of Java? How about Pascal?
Should I continue back in history to all the languages that implemented this feature decades ago?
C/C++ is a huge PITA with their nonsense compilation model which we shouldn't have copied verbatim in D.

On 5/4/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> What I'm saying is, it's completely possible to store the API in binary format *in* the object files, and use documentation generators to document

Yes but then you need to *modify* existing tools in order to add a new feature that extracts information from object files. Either that, or you'd have to somehow extract the .di files back from the object files. How else can you see the interface in your text editor without the source files? :)