Am 04.05.2012 19:54, schrieb Andrej Mitrovic:
> 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.

Delphi does this since ages!

On Fri, May 04, 2012 at 02:39:00PM -0700, Adam Wilson wrote:
> On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
[...]
> >Exactly. And while we're at it, *really* strip unnecessary stuff from .di files, like function bodies, template bodies, etc.. That stuff is required by the compiler, not the user, so stick that in the object files and let the compiler deal with it. The .di file should be ONLY what's needed for the user to understand how to use the library.
[...]
> I've written code to do this, but apparently it breaks Phobos in the autotester. I can't get it to break Phobos on my local machine so I'm at a loss as how to fix it. Maybe you can help? The code is here: https://github.com/LightBender/dmd.git
[...]

Sorry for taking so long to respond, been busy. Got some time this morning to cloned your repo and built dmd, then rebuilt druntime and phobos, and got this error from phobos:

../druntime/import/core/sys/posix/sys/select.di(25): function declaration without return type. (Note that constructors are always named 'this')
../druntime/import/core/sys/posix/sys/select.di(25): no identifier for declarator __FDELT(int d)
../druntime/import/core/sys/posix/sys/select.di(27): function declaration without return type. (Note that constructors are always named 'this')
../druntime/import/core/sys/posix/sys/select.di(27): no identifier for declarator __FDMASK(int d)
make[1]: *** [generated/linux/release/32/libphobos2.a] Error 1
make: *** [release] Error 2

Looks like the bug only triggers when you rebuild druntime before rebuilding phobos. Hope this helps. Let me know if you want me to test anything else.


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

On Sat, May 05, 2012 at 09:51:40AM -0700, H. S. Teoh wrote:
> On Fri, May 04, 2012 at 02:39:00PM -0700, Adam Wilson wrote:
> > On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> [...]
> > >Exactly. And while we're at it, *really* strip unnecessary stuff from .di files, like function bodies, template bodies, etc.. That stuff is required by the compiler, not the user, so stick that in the object files and let the compiler deal with it. The .di file should be ONLY what's needed for the user to understand how to use the library.
> [...]
> > I've written code to do this, but apparently it breaks Phobos in the autotester. I can't get it to break Phobos on my local machine so I'm at a loss as how to fix it. Maybe you can help? The code is here: https://github.com/LightBender/dmd.git
> [...]
> 
> Sorry for taking so long to respond, been busy. Got some time this morning to cloned your repo and built dmd, then rebuilt druntime and phobos, and got this error from phobos:
> 
> ../druntime/import/core/sys/posix/sys/select.di(25): function declaration without return type. (Note that constructors are always named 'this')
> ../druntime/import/core/sys/posix/sys/select.di(25): no identifier for declarator __FDELT(int d)
> ../druntime/import/core/sys/posix/sys/select.di(27): function declaration without return type. (Note that constructors are always named 'this')
> ../druntime/import/core/sys/posix/sys/select.di(27): no identifier for declarator __FDMASK(int d)
> make[1]: *** [generated/linux/release/32/libphobos2.a] Error 1
> make: *** [release] Error 2
[...]

Oh, and here's the snippet from the offending file
(core/sys/posix/sys/select.di):

------SNIP------
		private
		{
			alias c_long __fd_mask;
			enum uint __NFDBITS = 8 * __fd_mask.sizeof;
			extern (D) auto __FDELT(int d);		// this is line 25

			extern (D) auto __FDMASK(int d);	// this is line 27

		}
------SNIP------

Looks like the problem is caused by the auto, perhaps?


T

-- 
Lottery: tax on the stupid. -- Slashdotter

On Thursday, 3 May 2012 at 22:53:03 UTC, Alex Rønne Petersen
wrote:
> Absolutely possible, though too late for this year's GSoC. If you're still interested in working on it for GSoC 2013 (if Google decides to do another GSoC (which they most likely will)), then be sure to submit a proposal!
Too bad for me i guess, but i'll still try to get into my
university's SoC-program. And it'd be better to start the project
now compared to waiting for a year to start ;p

> Sounds like a good idea to me. Though in my personal opinion, you should try to make the linker as platform-agnostic as possible, so it's easy to adapt for new platforms / file formats.

Thanks! I'll try to make it modular and awesome in the end, but
for a start i'll just aim to make a linker that's usable with dmd
on windows. It's easier to make a good design after getting some
more hands-on experience, i think.

> As for resources on linkers, I think your best bet is reading the LLVM and GCC source code. I think someone also started an LLVM (machine code) linker project recently, but I don't know where to find it.

Guess i've got some interesting reading to do.. =)
I've come across http://www.iecc.com/linker/ which is quite
interesting to read. It seems that it is "quite old", but i don't
know how much the linker infrastructure has progressed the last
ten years so it's probably still reasonably up to date, i hope ;p

On Thursday, 3 May 2012 at 23:47:26 UTC, Trass3r wrote:

> Imho changing dmd to use COFF (incl. 64 support) instead of that crappy OMF would be more beneficial than yet another linker.

I'd love to, but i don't think i can spend a whole summer doing that ;)

>
> 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.

I intend to first make something that works and gather experience and get a firm graps of all the quirks of writing a linker first. And there seems to be nice features such as dead code elimination and template magic to consider as well. Would be a shame to limit the capabilities by making the design to well defined in the beginning of the project, i think.
So i'll defer the modularity & cross-platforminess for now but keep it in mind for the long run :)

Delphi, Turbo Pascal and FreePascal do the same.

All the required information is stored in the tpu/fpu files (Turbo/Free Pascal Unit).

A command line tool or IDE support easily show the unit interface.

--
Paulo

"foobar"  wrote in message news:abzrrvpylkxhdzsdhesg@forum.dlang.org...

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. 

AST/symbol table manipulation is way faster than reparsing code.

People keep talking about D and Go compilation speed, while I was already
enjoying such compile times back in 1990 with Turbo Pascal in computers much
less powerfull than my laptop.

But C and C++ with their 70's compiler technology, somehow won the market share,
and then people started complaining about compilation speeds.

Adele Golberg, once wrote a paper telling how C made the compiler technology
regress several decades.

--
Paulo

"Alex Rønne Petersen"  wrote in message news:jo1s2b$2bie$1@digitalmars.com...

On Friday 04 May 2012 08:56 PM, Andrew Wiley wrote:
> On Fri, May 4, 2012 at 1:46 PM, foobar <foo@bar.com
> <mailto:foo@bar.com>> wrote:
>
>     On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
>
>         On 5/4/12, foobar <foo@bar.com <mailto: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.
>
>
> I like the idea, but what about templates? For them, you'd basically be
> stuffing source code into the object files (unless you came up with a
> way to store the AST, but that seems like the effort/benefit ratio
> wouldn't be worth it since we currently have no way to preserve an AST
> tree between compiler runs).
> Otherwise, I find this idea very compelling. I'm sure there are probably
> other issues, though.
>

Storing the AST would basically equal storing the source code except
'trivia' like white space and unneeded tokens. At that point, you may as
well ship the source.

-- 
- Alex 

I also don't see the issue.

This is already a long tradition in the languages that don't have to carry C linker baggage.

- Turbo Pascal 4.0, 1987
- Oberon 1.0, 1986

So I also don't why a 2012 language can't have a similar mechanism.

--
Paulo

"Andrej Mitrovic"  wrote in message news:mailman.324.1336158548.24740.digitalmars-d@puremagic.com...

On 5/4/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> Current tools:  read .di files and extract API
> new tools: read .dobj files and extract API.
>
> I'm not really seeing the difficulty here...

I thought he meant libraries that are only distributed in binary form.
So no .di files anywhere. Maybe I misunderstood.. 

I really really think that mankind did a wrong turn when C won over Pascal
in the 80's.

And that Wirth somehow lost interest in the industry and did not try to push
Modula-* or Oberon. There are some papers where he states this.

Now we suffer from

- daggling pointers
- buffer overflows
- pre-historic compiler toolchains

With luck, Spec#, Go or more nicely D, will put us back on track.

--
Paulo

"dennis luehring"  wrote in message news:jo2kb8$htd$1@digitalmars.com...

Am 05.05.2012 09:06, schrieb dennis luehring:
> Am 04.05.2012 20:26, schrieb Steven Schveighoffer:
>>  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
>
> ever heard about Turbo Pascal (and delphi) got this feature since turbo
> pascal 4 around 1987
>
> and turbo pascal and delphi are extremely fast native compilers without
> any Java, .Net magic

an more up-to-date example can be seen using the freepascal compiler and
its ppdump tool: http://www.freepascal.org/tools/ppudump.var

and turbo pascal gots even since 1987 a very good package system like a
Java Jar file - you can just integrate compiled pascal sources (.pas ->
.tpu) into something called .tpl file (turbo pascal library)

the freepascal compiler got something similar called .ppl

these "technologies" are damn good and invented so long before - but
sometimes totaly unknown to all the obj-file-linker-guys 

Paulo Pinto wrote:
> AST/symbol table manipulation is way faster than reparsing code.
> 
> People keep talking about D and Go compilation speed, while I was already enjoying such compile times back in 1990 with Turbo Pascal in computers much less powerfull than my laptop.
> 
> But C and C++ with their 70's compiler technology, somehow won the
> market share,
> and then people started complaining about compilation speeds.
> 
> Adele Golberg, once wrote a paper telling how C made the compiler technology regress several decades.

Do you happen to remember to exact title of that paper? Thanks.

Jens