On 5/4/12, Pierre LeMoine yarr.luben+dl...@gmail.com wrote:
I'm interested in starting a project to make a linker besides
optlink for dmd on windows.
I've found this randomly in my links (ELF Linux linker, but still
might be useful info): http://research.google.com/pubs/pub34417.html
The
The correct link should have been
http://uhaweb.hartford.edu/ccscne/Allen.pdf
Am 08.05.2012 04:33, schrieb Andre Tampubolon:
Interesting reading.
I took a look at page 23, and didn't find the mention of C.
Maybe I didn't read carefully?
On 5/8/2012 3:34 AM, Paulo Pinto wrote:
Hi,
it seems I
Am 04.05.2012 01:47, schrieb Trass3r:
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
On Mon, 07 May 2012 12:41:09 -0300, Pierre LeMoine yarr.luben+dl...@gmail.com
wrote:
On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote:
If you are interested in getting results rather than
reinventing the wheel,
I would advice you to have a look at the openwatcom.org wlink,
and the
On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
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
Paulo Pinto wrote:
On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
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
Am 07.05.2012 07:53, schrieb Paulo Pinto:
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
-
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
Purity inference won't happen either way. Purity is part of your API and
also meant to help you reason about your code. If the compiler just
infers purity in a function and you later change the
On Sat, 05 May 2012 03:06:52 -0400, dennis luehring dl.so...@gmx.net
wrote:
Am 04.05.2012 20:26, schrieb Steven Schveighoffer:
On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 5/4/12, foobarf...@bar.com wrote:
How about augmenting the object
On 07-05-2012 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
Purity inference won't happen either way. Purity is part of your API
and also meant to help you reason about your code. If the compiler
just infers purity in a
On 05/07/12 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen xtzgzo...@gmail.com
wrote:
Purity inference won't happen either way. Purity is part of your API and
also meant to help you reason about your code. If the compiler just infers
purity in
I think it was there where I read about it.
I'll update you if I have any success, otherwise I need to retract my
statement. :(
--
Paulo
Jens Mueller wrote in message
news:mailman.380.1336380192.24740.digitalmar...@puremagic.com...
Paulo Pinto wrote:
On Monday, 7 May 2012 at 07:26:44
On 07-05-2012 14:50, Steven Schveighoffer wrote:
On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
On 07-05-2012 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
Purity inference won't
I like the idea, need to check what information I could provide.
Wirth's books about Oberon also provide similar information.
--
Paulo
dennis luehring wrote in message news:jo85t1$1n9b$1...@digitalmars.com...
Am 07.05.2012 07:53, schrieb Paulo Pinto:
I really really think that mankind did a
On Mon, 07 May 2012 09:22:05 -0400, Paulo Pinto pj...@progtools.org
wrote:
This just confirms what I saw yesterday on a presentation.
Many developers re-invent the wheel, or jump to the fad technology of the
year, because they don't have the knowledge of old already proven
technologies,
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
On 07-05-2012 14:50, Steven Schveighoffer wrote:
On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
On 07-05-2012 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012
On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote:
If you are interested in getting results rather than
reinventing the wheel,
I would advice you to have a look at the openwatcom.org wlink,
and the
forked jwlink as a starting point. The linker is open source,
written in
C and has user
On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley
wiley.andre...@gmail.com wrote:
On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer
schvei...@yahoo.comwrote:
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen
That's exactly what storing the interface in the object file does. You
On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer
schvei...@yahoo.comwrote:
On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley wiley.andre...@gmail.com
wrote:
On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer schvei...@yahoo.com
wrote:
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne
On Mon, May 07, 2012 at 07:21:54PM +0200, Paulo Pinto wrote:
[...]
I have spent a huge time in the university learning about compiler
development, reading old books and papers from the early computing
days.
So in a general way, and not directed to you now, I saddens me that a
great part of
On Mon, 07 May 2012 13:34:49 -0400, Andrew Wiley
wiley.andre...@gmail.com wrote:
On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer
schvei...@yahoo.comwrote:
I agree that's the case with the current object/linker model. Something
that puts inferred properties into the object file needs
On 2012-05-07 17:41, Pierre LeMoine wrote:
On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote:
If you are interested in getting results rather than reinventing the
wheel,
I would advice you to have a look at the openwatcom.org wlink, and the
forked jwlink as a starting point. The linker is
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
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
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:abzrrvpylkxhdzsdh...@forum.dlang.org...
On
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
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
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
-
Am 04.05.2012 20:26, schrieb Steven Schveighoffer:
On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 5/4/12, foobarf...@bar.com wrote:
How about augmenting the object format so that libraries would be
self contained and would not require additional
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.mitrov...@gmail.com wrote:
On 5/4/12, foobarf...@bar.com wrote:
How about augmenting the object format so that libraries would
On 2012-05-05 00:39, H. S. Teoh wrote:
It's often impossible to debug something if you don't get to see what
the compiler sees. I suppose you could argue that leaving out function
bodies and stuff amounts to the same thing, but at least the language's
interface for a function is the function's
On Friday, 4 May 2012 at 22:38:27 UTC, H. S. Teoh wrote:
On Sat, May 05, 2012 at 12:07:16AM +0200, foobar wrote:
On Friday, 4 May 2012 at 21:11:22 UTC, H. S. Teoh wrote:
Exactly. And while we're at it, *really* strip unnecessary
stuff from
.di files, like function bodies, template bodies,
Am 04.05.2012 19:54, schrieb Andrej Mitrovic:
On 5/4/12, foobarf...@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
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
hst...@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
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
hst...@quickfur.ath.cx wrote:
[...]
Exactly. And while we're at it, *really* strip unnecessary stuff from
.di files,
On 2012-05-04 01:57, H. S. Teoh wrote:
To be frank, I question the wisdom of not just using ld on Posix
systems... but OTOH, the world *needs* better linker technology than we
currently have, so this projects like this one is a good thing.
He can start with a version for Windows. If as much
On Thu, 03 May 2012 19:47:24 -0400, Trass3r u...@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.
+1
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
On Fri, 04 May 2012 18:57:44 +0200, foobar f...@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
On 5/4/12, foobar f...@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
On 5/4/12, Trass3r u...@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
On Friday, 4 May 2012 at 17:52:54 UTC, simendsjo wrote:
On Fri, 04 May 2012 18:57:44 +0200, foobar f...@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
On Friday, 4 May 2012 at 17:54:47 UTC, Andrej Mitrovic wrote:
On 5/4/12, foobar f...@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
On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 5/4/12, foobar f...@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
On 5/4/12, foobar f...@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
On 5/4/12, Steven Schveighoffer schvei...@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.mitrov...@gmail.com wrote:
On 5/4/12, Steven Schveighoffer schvei...@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
On 5/4/12, Steven Schveighoffer schvei...@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
On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
On 5/4/12, foobar f...@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
On Fri, 04 May 2012 14:48:04 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 5/4/12, Steven Schveighoffer schvei...@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
On 5/4/12, Steven Schveighoffer schvei...@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.
On Fri, 04 May 2012 15:07:43 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 5/4/12, Steven Schveighoffer schvei...@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
On Fri, May 4, 2012 at 1:46 PM, foobar f...@bar.com wrote:
On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
On 5/4/12, foobar f...@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
On 2012-05-04 18:57, foobar 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?
That would be nice. I guess that would mean
On 2012-05-04 20:30, Andrej Mitrovic wrote:
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.
Then you need to manage your docs better.
And then what
On Friday, 4 May 2012 at 19:13:21 UTC, Steven Schveighoffer wrote:
On Fri, 04 May 2012 15:07:43 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 5/4/12, Steven Schveighoffer schvei...@yahoo.com wrote:
Current tools: read .di files and extract API
new tools: read .dobj files and
On Friday, 4 May 2012 at 19:21:02 UTC, Andrew Wiley wrote:
On Fri, May 4, 2012 at 1:46 PM, foobar f...@bar.com wrote:
On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
On 5/4/12, foobar f...@bar.com wrote:
The di files are mostly meant to be machine read (e.g. the
compiler) and
On Fri, 04 May 2012 14:56:56 -0400, Andrew Wiley
wiley.andre...@gmail.com wrote:
I like the idea, but what about templates? For them, you'd basically be
stuffing source code into the object files
Nothing wrong with this. There is still a gain here -- object code
compiled from the source
On Fri, May 04, 2012 at 07:54:38PM +0200, Andrej Mitrovic wrote:
On 5/4/12, foobar f...@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
On Fri, May 04, 2012 at 03:13:21PM -0400, Steven Schveighoffer wrote:
[...]
I think he meant that object (and library) binary files would be
augmented by API segments that provide what di files provide now --
an interface-only version of the code. It doesn't have to be text,
it can be binary
On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Fri, May 04, 2012 at 07:54:38PM +0200, Andrej Mitrovic wrote:
On 5/4/12, foobar f...@bar.com wrote:
How about augmenting the object format so that libraries would be
self contained and would not require
On Friday, 4 May 2012 at 21:11:22 UTC, H. S. Teoh 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
On Sat, May 05, 2012 at 12:07:16AM +0200, foobar wrote:
On Friday, 4 May 2012 at 21:11:22 UTC, H. S. Teoh 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,
On Friday 04 May 2012 08:56 PM, Andrew Wiley wrote:
On Fri, May 4, 2012 at 1:46 PM, foobar f...@bar.com
mailto:f...@bar.com wrote:
On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
On 5/4/12, foobar f...@bar.com mailto:f...@bar.com wrote:
The di files are
On Friday 04 May 2012 11:17 PM, H. S. Teoh wrote:
On Fri, May 04, 2012 at 03:13:21PM -0400, Steven Schveighoffer wrote:
[...]
I think he meant that object (and library) binary files would be
augmented by API segments that provide what di files provide now --
an interface-only version of the
On 04-05-2012 00:47, Pierre LeMoine wrote:
Hi!
I'm interested in starting a project to make a linker besides optlink
for dmd on windows. If possible it'd be cool to run it as a
gsoc-project, but if that's not an option I'll try to get it admitted as
a soc-project at my university.
Absolutely
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
On Fri, May 04, 2012 at 12:53:02AM +0200, Alex Rønne Petersen wrote:
On 04-05-2012 00:47, Pierre LeMoine wrote:
[...]
Anyway, the project would aim to be a replacement or alternative to
optlink on windows. I've personally encountered quite a few seemingly
random problems with optlink, and the
On 04-05-2012 01:57, H. S. Teoh wrote:
On Fri, May 04, 2012 at 12:53:02AM +0200, Alex Rønne Petersen wrote:
On 04-05-2012 00:47, Pierre LeMoine wrote:
[...]
Anyway, the project would aim to be a replacement or alternative to
optlink on windows. I've personally encountered quite a few
On Fri, May 04, 2012 at 02:43:34AM +0200, Alex Rønne Petersen wrote:
On 04-05-2012 01:57, H. S. Teoh wrote:
[...]
The problem with writing linkers is that they are usually closely
tied to implementation details on the host OS.
[...]
I know, but that doesn't mean you can't write the linker so
70 matches
Mail list logo
