As you may all be aware, I've been trying to improve the automated
generation of .di files and I now have something that I feel is testable.
Currently the new code only makes the following changes.
1. Function Implementations are removed
2. Private Function Declarations are removed.
On Monday, 19 December 2011 at 08:11:26 UTC, Adam Wilson wrote:
Let me know what you think!
Nice work! I think this is going to be more and more relevant now
that the situation with shared libraries is getting more
interesting in D.
I would argue that anything that can't be moved to a diffe
Good work Adam!
After class/struct/interface level "export" we shouldn't need it again.
It already implies that everything (if not stated otherwise via private)
will be exported.
Removing them also would automagicaly solve the inconsistency below.
export class List : IList
{
export voi
On Mon, 19 Dec 2011 10:11:25 +0200, Adam Wilson wrote:
Everything else is left alone. Templates and mixins are not addressed
with this code and *should* not be modified. That's where I need your
help, the test cases I have written cover some basic scenarios but I
don't have the capability
On Mon, 19 Dec 2011 14:11:31 +0200, so wrote:
On Mon, 19 Dec 2011 10:11:25 +0200, Adam Wilson
wrote:
Everything else is left alone. Templates and mixins are not addressed
with this code and *should* not be modified. That's where I need your
help, the test cases I have written cover some
On Monday, 19 December 2011 at 12:11:32 UTC, so wrote:
On Mon, 19 Dec 2011 10:11:25 +0200, Adam Wilson
wrote:
Everything else is left alone. Templates and mixins are not
addressed with this code and *should* not be modified. That's
where I need your help, the test cases I have written cover
On Mon, 19 Dec 2011 14:43:07 +0200, Jakob Ovrum
wrote:
On Monday, 19 December 2011 at 12:11:32 UTC, so wrote:
On Mon, 19 Dec 2011 10:11:25 +0200, Adam Wilson
wrote:
Everything else is left alone. Templates and mixins are not addressed
with this code and *should* not be modified. That's
On 19.12.2011 09:11, Adam Wilson wrote:
Currently, I feel that private imports should be stripped from the DI
file as they are intended to be internal to the module. However, I want
to put it to the community to decide, and I would especially appreciate
Mr. Bright's opinion on private imports i
On Mon, 19 Dec 2011 14:22:10 +0100, Rainer Schuetze
wrote:
On 19.12.2011 09:11, Adam Wilson wrote:
Currently, I feel that private imports should be stripped from the DI
file as they are intended to be internal to the module. However, I want
to put it to the community to decide, and I would
On 12/19/11 2:11 AM, Adam Wilson wrote:
As you may all be aware, I've been trying to improve the automated
generation of .di files and I now have something that I feel is
testable. Currently the new code only makes the following changes.
1. Function Implementations are removed
2. Private Functio
On Mon, 19 Dec 2011 03:53:27 -0800, so wrote:
Good work Adam!
After class/struct/interface level "export" we shouldn't need it again.
It already implies that everything (if not stated otherwise via private)
will be exported.
Well, I tried it that way and it didn't work on Windows. Without
On Mon, 19 Dec 2011 08:53:21 -0800, Andrei Alexandrescu
wrote:
On 12/19/11 2:11 AM, Adam Wilson wrote:
As you may all be aware, I've been trying to improve the automated
generation of .di files and I now have something that I feel is
testable. Currently the new code only makes the following
Btw Adam, a long long time ago (well, few years ago) there was an
effort for better DLL support in D: http://dsource.org/projects/ddl/
There was also a presentation here: http://vimeo.com/2264486 and
slides:
http://replay.waybackmachine.org/20081203030930/http://team0xf.com/conference/DDL.pdf
An
On Monday, December 19, 2011 10:53:21 Andrei Alexandrescu wrote:
> You may want to generate DIs for Phobos and take a look at them. Phobos
> uses a vast array of D's capabilities so it's an effective unittest for
> DI generation.
It's a great test ground, but I wouldn't want to see Phobos actually
On Mon, 19 Dec 2011 04:57:54 -0800, so wrote:
On Mon, 19 Dec 2011 14:43:07 +0200, Jakob Ovrum
wrote:
On Monday, 19 December 2011 at 12:11:32 UTC, so wrote:
On Mon, 19 Dec 2011 10:11:25 +0200, Adam Wilson
wrote:
Everything else is left alone. Templates and mixins are not addressed
wi
On Mon, 19 Dec 2011 06:27:20 -0800, Martin Nowak wrote:
On Mon, 19 Dec 2011 14:22:10 +0100, Rainer Schuetze
wrote:
On 19.12.2011 09:11, Adam Wilson wrote:
Currently, I feel that private imports should be stripped from the DI
file as they are intended to be internal to the module. Howeve
On Mon, 19 Dec 2011 09:36:27 -0800, Andrej Mitrovic
wrote:
Btw Adam, a long long time ago (well, few years ago) there was an
effort for better DLL support in D: http://dsource.org/projects/ddl/
There was also a presentation here: http://vimeo.com/2264486 and
slides:
http://replay.waybackma
On Mon, 19 Dec 2011 22:24:18 +0200, Adam Wilson wrote:
So the consensus is to keep all private members/imports/etc?
Ideally to get most out of the auto generation of di files (by definition
of module system) we need to strip ALL private stuff.
Only this way we can say the automation is on
On Mon, 19 Dec 2011 23:04:27 +0200, so wrote:
On Mon, 19 Dec 2011 22:24:18 +0200, Adam Wilson
wrote:
So the consensus is to keep all private members/imports/etc?
Ideally to get most out of the auto generation of di files (by
definition of module system) we need to strip ALL private stu
On Monday, 19 December 2011 at 21:04:28 UTC, so wrote:
On Mon, 19 Dec 2011 22:24:18 +0200, Adam Wilson
wrote:
So the consensus is to keep all private members/imports/etc?
Ideally to get most out of the auto generation of di files (by
definition of module system) we need to strip ALL privat
On Mon, 19 Dec 2011 15:53:02 -0800, Jakob Ovrum
wrote:
On Monday, 19 December 2011 at 21:04:28 UTC, so wrote:
On Mon, 19 Dec 2011 22:24:18 +0200, Adam Wilson
wrote:
So the consensus is to keep all private members/imports/etc?
Ideally to get most out of the auto generation of di files
On Mon, 19 Dec 2011 08:53:21 -0800, Andrei Alexandrescu
wrote:
On 12/19/11 2:11 AM, Adam Wilson wrote:
As you may all be aware, I've been trying to improve the automated
generation of .di files and I now have something that I feel is
testable. Currently the new code only makes the following
On Mon, 19 Dec 2011 00:11:25 -0800, Adam Wilson wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the following issues:
1. Privates should exist in the DI file to support public templates.
2. Template classes and functions retain their im
Derelict works ok now, good work!
However, the .di files end up eating newlines.
Before:
double ALLEGRO_USECS_TO_SECS(long x)
{
return x / 1e+06;
}
double ALLEGRO_MSECS_TO_SECS(long x)
{
return x / 1000;
}
double ALLEGRO_BPS_TO_SECS(int x)
{
return 1 / x;
}
After:
double ALLEGRO_USECS_TO_SECS(lo
On 12/20/11 2:03 AM, Adam Wilson wrote:
On Mon, 19 Dec 2011 00:11:25 -0800, Adam Wilson wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the following issues:
1. Privates should exist in the DI file to support public templates.
2. Template classes a
On Tue, 20 Dec 2011 04:41:11 -0800, Andrei Alexandrescu
wrote:
On 12/20/11 2:03 AM, Adam Wilson wrote:
On Mon, 19 Dec 2011 00:11:25 -0800, Adam Wilson
wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the following issues:
1. Privates should e
On Tue, 20 Dec 2011 03:49:35 -0800, Andrej Mitrovic
wrote:
Derelict works ok now, good work!
This is fantastic news! Thanks for helping to test these changes. :-)
However, the .di files end up eating newlines.
Before:
double ALLEGRO_USECS_TO_SECS(long x)
{
return x / 1e+06;
}
double ALLE
Am 19.12.2011 09:11, schrieb Adam Wilson:
As you may all be aware, I've been trying to improve the automated
generation of .di files and I now have something that I feel is
testable. Currently the new code only makes the following changes.
1. Function Implementations are removed
2. Private Funct
On 12/21/2011 04:58 PM, Benjamin Thaut wrote:
Am 19.12.2011 09:11, schrieb Adam Wilson:
As you may all be aware, I've been trying to improve the automated
generation of .di files and I now have something that I feel is
testable. Currently the new code only makes the following changes.
1. Functi
On 12/21/11 2:12 AM, Adam Wilson wrote:
On Tue, 20 Dec 2011 04:41:11 -0800, Andrei Alexandrescu
wrote:
On 12/20/11 2:03 AM, Adam Wilson wrote:
On Mon, 19 Dec 2011 00:11:25 -0800, Adam Wilson
wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the fo
On Wed, 21 Dec 2011 08:41:43 -0800, Andrei Alexandrescu
wrote:
On 12/21/11 2:12 AM, Adam Wilson wrote:
On Tue, 20 Dec 2011 04:41:11 -0800, Andrei Alexandrescu
wrote:
On 12/20/11 2:03 AM, Adam Wilson wrote:
On Mon, 19 Dec 2011 00:11:25 -0800, Adam Wilson
wrote:
The latest DI generation
On 12/21/11 10:42 AM, Adam Wilson wrote:
Oops! I mean't a pull on dmd for the new DI code. Sorry for the confusion!
Yes, absolutely!
Andrei
On Wednesday, 21 December 2011 at 16:42:59 UTC, Adam Wilson wrote:
Oops! I mean't a pull on dmd for the new DI code. Sorry for the
confusion!
Pull requests are always appreciated! :)
Remember, it's more like
"please-review-and-pull-if-of-acceptable-quality request" :P
The latest DI generation code is now on my Git account and ready for
testing. It fixes the following issues:
1. Variables in template functions/classes would be stripped of their
initializers.
2. Manifest Constants would lose their initializers.
DI generation is getting close! Every Ph
On 2011-12-22 08:07, Adam Wilson wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the following issues:
1. Variables in template functions/classes would be stripped of their
initializers.
2. Manifest Constants would lose their initializers.
DI genera
On 12/22/11 1:07 AM, Adam Wilson wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the following issues:
1. Variables in template functions/classes would be stripped of their
initializers.
2. Manifest Constants would lose their initializers.
DI genera
On Thu, 22 Dec 2011 08:46:39 -0800, Andrei Alexandrescu
wrote:
On 12/22/11 1:07 AM, Adam Wilson wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the following issues:
1. Variables in template functions/classes would be stripped of their
initializ
On Wed, 21 Dec 2011 23:43:56 -0800, Jacob Carlborg wrote:
On 2011-12-22 08:07, Adam Wilson wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the following issues:
1. Variables in template functions/classes would be stripped of their
initializers.
2.
On 2011-12-22 18:33, Adam Wilson wrote:
On Wed, 21 Dec 2011 23:43:56 -0800, Jacob Carlborg wrote:
On 2011-12-22 08:07, Adam Wilson wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the following issues:
1. Variables in template functions/classes wo
On Thu, 22 Dec 2011 13:02:49 -0800, Jacob Carlborg wrote:
On 2011-12-22 18:33, Adam Wilson wrote:
On Wed, 21 Dec 2011 23:43:56 -0800, Jacob Carlborg wrote:
On 2011-12-22 08:07, Adam Wilson wrote:
The latest DI generation code is now on my Git account and ready for
testing. It fixes the fol
On 2011-12-23 01:22, Adam Wilson wrote:
On Thu, 22 Dec 2011 13:02:49 -0800, Jacob Carlborg wrote:
Never mind, it seems to be working.
Did you check it against my forked code? I want to make sure that there
are as few errors as possible before I open up the pull. :-)
No, I checked with DMD
On 12/19/11, Adam Wilson wrote:
> If anyone wishes to test my changes against their code, you can download
> them from my git account here:
> https://lightben...@github.com/LightBender/dmd.git
This seems to work nicely even with the latest release. It's much
better than the current .di generation
On 3/14/12, Andrej Mitrovic wrote:
> This seems to work nicely even with the latest release. It's much
> better than the current .di generation for sure. Any plans on merging
> this with mainline before it goes stale?
Although I would really like to be able to keep documentation comments
in the .
On Wed, 14 Mar 2012 12:30:00 -0700, Andrej Mitrovic
wrote:
On 12/19/11, Adam Wilson wrote:
If anyone wishes to test my changes against their code, you can download
them from my git account here:
https://lightben...@github.com/LightBender/dmd.git
This seems to work nicely even with the lat
On Wed, 14 Mar 2012 12:35:03 -0700, Andrej Mitrovic
wrote:
On 3/14/12, Andrej Mitrovic wrote:
This seems to work nicely even with the latest release. It's much
better than the current .di generation for sure. Any plans on merging
this with mainline before it goes stale?
Although I would r
El 19/12/2011 9:11, Adam Wilson escribió:
1. Function Implementations are removed
What about function inlining? would it work from a different module?
I think the implementation of small functions should be kept so that
client code can inline them.
The current DMD does this apparently, it
On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro
wrote:
El 19/12/2011 9:11, Adam Wilson escribió:
1. Function Implementations are removed
What about function inlining? would it work from a different module?
I think the implementation of small functions should be kept so that
client code can
Adam Wilson:
I think I said this before, but for what it's worth,
I think your new approach is spot-on correct.
On 3/14/12, Adam Wilson wrote:
> I would fix the bug myself, but I am getting married in a month and am
> rather short on time.
That's ok I'm in no hurry just curious. Congrats on getting married! :)
On Wed, 14 Mar 2012 14:23:19 -0700, Andrej Mitrovic
wrote:
On 3/14/12, Adam Wilson wrote:
I would fix the bug myself, but I am getting married in a month and am
rather short on time.
That's ok I'm in no hurry just curious. Congrats on getting married! :)
Thank you! Hehe, well, I have bi
On Wed, 14 Mar 2012 14:17:28 -0700, Adam D. Ruppe
wrote:
Adam Wilson:
I think I said this before, but for what it's worth,
I think your new approach is spot-on correct.
Thank you. More importantly though, Walter and Andrei also agree, so in
the end, the inlinaholics can just deal. :-)
El 14/03/2012 22:13, Adam Wilson escribió:
> On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro
> wrote:
>
> The problem is that in DI generation, at least as near as I can tell, D
> has now idea how big a function is during DI generation. In my
> experience it was keeping all functions not just small on
On Wed, 14 Mar 2012 14:42:54 -0700, Alvaro
wrote:
El 14/03/2012 22:13, Adam Wilson escribió:
> On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro
> wrote:
>
> The problem is that in DI generation, at least as near as I can tell,
D
> has now idea how big a function is during DI generation. In
53 matches
Mail list logo
