Proposal: reinstate pre-built PLT for Dialyzer

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: reinstate pre-built PLT for Dialyzer

Sean Cribbs-3
Hi Erlangers,

Ages ago, OTP shipped with a pre-built PLT for dialyzer, which was removed
reasons forgotten by most of us (probably the time/cost of building it).
Nowadays, because dialyzer is much improved (parallelism!) and our
computers are faster and have more cores, a PLT for all of the standard
library might only take a few minutes to build.

We've been increasing our usage of dialyzer at Basho and I have felt that
it seems extremely wasteful and unnecessary to build a partial PLT of the
standard library for every single project, when that information only
changes across OTP releases. I feel the Erlang/OTP build process should
include building a PLT that encompasses the entire standard library. Aside
from the reduced cost of building PLTs for every different app, this may
encourage others to start using dialyzer on their projects.

I'm offering to do the work to make this happen, but I need a little
guidance on where to start. I've looked at the dialyzer Makefile from an
older release where the PLT was included, but I'm concerned the project
structure has changed enough that the rules there no longer apply. It seems
the dialyzer runtime itself might also need to be tweaked to automatically
include the prebuilt PLT.

Looking forward to hearing your thoughts and direction. Cheers!

--
Sean Cribbs <sean>
Software Engineer
Basho Technologies, Inc.
http://basho.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140116/59a1f9d5/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Proposal: reinstate pre-built PLT for Dialyzer

Michał Ptaszek
+1.


2014/1/16 Sean Cribbs <sean>

> Hi Erlangers,
>
> Ages ago, OTP shipped with a pre-built PLT for dialyzer, which was removed
> reasons forgotten by most of us (probably the time/cost of building it).
> Nowadays, because dialyzer is much improved (parallelism!) and our
> computers are faster and have more cores, a PLT for all of the standard
> library might only take a few minutes to build.
>
> We've been increasing our usage of dialyzer at Basho and I have felt that
> it seems extremely wasteful and unnecessary to build a partial PLT of the
> standard library for every single project, when that information only
> changes across OTP releases. I feel the Erlang/OTP build process should
> include building a PLT that encompasses the entire standard library. Aside
> from the reduced cost of building PLTs for every different app, this may
> encourage others to start using dialyzer on their projects.
>
> I'm offering to do the work to make this happen, but I need a little
> guidance on where to start. I've looked at the dialyzer Makefile from an
> older release where the PLT was included, but I'm concerned the project
> structure has changed enough that the rules there no longer apply. It seems
> the dialyzer runtime itself might also need to be tweaked to automatically
> include the prebuilt PLT.
>
> Looking forward to hearing your thoughts and direction. Cheers!
>
> --
> Sean Cribbs <sean>
> Software Engineer
> Basho Technologies, Inc.
> http://basho.com/
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches
> http://erlang.org/mailman/listinfo/erlang-patches
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140117/190c9a4f/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Proposal: reinstate pre-built PLT for Dialyzer

Ignas Vyšniauskas
In reply to this post by Sean Cribbs-3
On 01/16/2014 07:15 PM, Sean Cribbs wrote:
> We've been increasing our usage of dialyzer at Basho and I have felt
>  that it seems extremely wasteful and unnecessary to build a partial
>  PLT of the standard library for every single project, when that
> information only changes across OTP releases.

+1 also, but doesn't the `--add_to_plt` flag resolve the problem you
describe of having to build the PLT for every single project?

You build once the "global" / OTP plt, and then just append the needed
things from specific projects from that to obtain new PLTs.

--
Ignas

Reply | Threaded
Open this post in threaded view
|

Proposal: reinstate pre-built PLT for Dialyzer

Sean Cribbs-3
Sure, but my point is that there _is no global PLT_. OTP should have one
shipped in its standard library.


On Sat, Jan 18, 2014 at 9:54 AM, Ignas Vy?niauskas <baliulia>wrote:

> On 01/16/2014 07:15 PM, Sean Cribbs wrote:
> > We've been increasing our usage of dialyzer at Basho and I have felt
> >  that it seems extremely wasteful and unnecessary to build a partial
> >  PLT of the standard library for every single project, when that
> > information only changes across OTP releases.
>
> +1 also, but doesn't the `--add_to_plt` flag resolve the problem you
> describe of having to build the PLT for every single project?
>
> You build once the "global" / OTP plt, and then just append the needed
> things from specific projects from that to obtain new PLTs.
>
> --
> Ignas
>



--
Sean Cribbs <sean>
Software Engineer
Basho Technologies, Inc.
http://basho.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140118/6deea145/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Proposal: reinstate pre-built PLT for Dialyzer

Tuncer Ayaz-2
In reply to this post by Sean Cribbs-3
On Thu, Jan 16, 2014 at 7:15 PM, Sean Cribbs wrote:

> Hi Erlangers,
>
> Ages ago, OTP shipped with a pre-built PLT for dialyzer, which was
> removed reasons forgotten by most of us (probably the time/cost of
> building it). Nowadays, because dialyzer is much improved
> (parallelism!) and our computers are faster and have more cores, a
> PLT for all of the standard library might only take a few minutes to
> build.
>
> We've been increasing our usage of dialyzer at Basho and I have felt
> that it seems extremely wasteful and unnecessary to build a partial
> PLT of the standard library for every single project, when that
> information only changes across OTP releases. I feel the Erlang/OTP
> build process should include building a PLT that encompasses the
> entire standard library. Aside from the reduced cost of building
> PLTs for every different app, this may encourage others to start
> using dialyzer on their projects.

How do you define the standard library? I mean, why not include
all libs/apps?

I usually build a comprehensive PLT for each OTP release and
unfortunately that uncovers type errors which should not be shipped in
a release :(.

> I'm offering to do the work to make this happen, but I need a little
> guidance on where to start. I've looked at the dialyzer Makefile
> from an older release where the PLT was included, but I'm concerned
> the project structure has changed enough that the rules there no
> longer apply. It seems the dialyzer runtime itself might also need
> to be tweaked to automatically include the prebuilt PLT.
>
> Looking forward to hearing your thoughts and direction. Cheers!

>From what I recall, a PLT references the beam files with absolute
filenames. This might pose a problem you'd have to solve first.

Reply | Threaded
Open this post in threaded view
|

Proposal: reinstate pre-built PLT for Dialyzer

Sean Cribbs-3
On Thu, Jan 23, 2014 at 9:18 AM, Tuncer Ayaz <tuncer.ayaz> wrote:

>
> How do you define the standard library? I mean, why not include
> all libs/apps?
>

Yes, that is exactly what I mean. Anything that ships with OTP and is not
explicitly disabled or skipped by the build process should be included.


>
> I usually build a comprehensive PLT for each OTP release and
> unfortunately that uncovers type errors which should not be shipped in
> a release :(.
>
>
And we should be fixing those! :D


> From what I recall, a PLT references the beam files with absolute
> filenames. This might pose a problem you'd have to solve first.
>

Thank you for pointing that out. I'll look into that.

--
Sean Cribbs <sean>
Software Engineer
Basho Technologies, Inc.
http://basho.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140123/946a65ca/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Proposal: reinstate pre-built PLT for Dialyzer

Tuncer Ayaz-2
On Thu, Jan 23, 2014 at 4:31 PM, Sean Cribbs wrote:

> On Thu, Jan 23, 2014 at 9:18 AM, Tuncer Ayaz wrote:
>>
>>
>> How do you define the standard library? I mean, why not include all
>> libs/apps?
>
>
> Yes, that is exactly what I mean. Anything that ships with OTP and
> is not explicitly disabled or skipped by the build process should be
> included.
>
>>
>>
>> I usually build a comprehensive PLT for each OTP release and
>> unfortunately that uncovers type errors which should not be shipped
>> in a release :(.
>>
>
> And we should be fixing those! :D

See https://github.com/erlang/otp/pull/166.

Unfortunately the one issue that needs discussion and decision-making
by the OTP team has been reported and gone unfixed for a couple
releases.
See http://erlang.org/pipermail/erlang-bugs/2013-September/003765.html

>> From what I recall, a PLT references the beam files with absolute
>> filenames. This might pose a problem you'd have to solve first.
>
>
> Thank you for pointing that out. I'll look into that.

BTW, assuming this gets off the ground, would you suggest distributing
the PLT with the tarball or in the git tree? I think the src tarball
and maybe a separate tarball make more sense. For reference, my local
R16B03 PLT is 4MB. This would also be in line with other generated
files like configure scripts (what's generated vs what's edited). In
the git tree it would only make sense to be included in a tagged tree,
but that may be confusing, so release tarballs make the most sense to
me.

Reply | Threaded
Open this post in threaded view
|

Proposal: reinstate pre-built PLT for Dialyzer

Sean Cribbs-3
On Thu, Jan 23, 2014 at 9:56 AM, Tuncer Ayaz <tuncer.ayaz> wrote:

> BTW, assuming this gets off the ground, would you suggest distributing
> the PLT with the tarball or in the git tree? I think the src tarball
> and maybe a separate tarball make more sense. For reference, my local
> R16B03 PLT is 4MB. This would also be in line with other generated
> files like configure scripts (what's generated vs what's edited). In
> the git tree it would only make sense to be included in a tagged tree,
> but that may be confusing, so release tarballs make the most sense to
> me.
>

Neither. If you build OTP from source, it would be built during the normal
build/install process. If you download a prebuilt binary package (Windows
or something from ESL or a distribution maintainer), the PLT should be
included in that package.

--
Sean Cribbs <sean>
Software Engineer
Basho Technologies, Inc.
http://basho.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20140123/f3c43e01/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Proposal: reinstate pre-built PLT for Dialyzer

Tuncer Ayaz-2
On Thu, Jan 23, 2014 at 5:19 PM, Sean Cribbs <sean> wrote:

> On Thu, Jan 23, 2014 at 9:56 AM, Tuncer Ayaz <tuncer.ayaz> wrote:
>>
>> BTW, assuming this gets off the ground, would you suggest
>> distributing the PLT with the tarball or in the git tree? I think
>> the src tarball and maybe a separate tarball make more sense. For
>> reference, my local R16B03 PLT is 4MB. This would also be in line
>> with other generated files like configure scripts (what's generated
>> vs what's edited). In the git tree it would only make sense to be
>> included in a tagged tree, but that may be confusing, so release
>> tarballs make the most sense to me.
>
>
> Neither. If you build OTP from source, it would be built during the
> normal build/install process. If you download a prebuilt binary
> package (Windows or something from ESL or a distribution
> maintainer), the PLT should be included in that package.

That sounds good to me.

Reply | Threaded
Open this post in threaded view
|

Re: Proposal: reinstate pre-built PLT for Dialyzer

Tuncer Ayaz
On Thu, Jan 23, 2014 at 5:34 PM, Tuncer Ayaz <[hidden email]> wrote:

> On Thu, Jan 23, 2014 at 5:19 PM, Sean Cribbs <[hidden email]> wrote:
>> On Thu, Jan 23, 2014 at 9:56 AM, Tuncer Ayaz <[hidden email]> wrote:
>>>
>>> BTW, assuming this gets off the ground, would you suggest
>>> distributing the PLT with the tarball or in the git tree? I think
>>> the src tarball and maybe a separate tarball make more sense. For
>>> reference, my local R16B03 PLT is 4MB. This would also be in line
>>> with other generated files like configure scripts (what's generated
>>> vs what's edited). In the git tree it would only make sense to be
>>> included in a tagged tree, but that may be confusing, so release
>>> tarballs make the most sense to me.
>>
>>
>> Neither. If you build OTP from source, it would be built during the
>> normal build/install process. If you download a prebuilt binary
>> package (Windows or something from ESL or a distribution
>> maintainer), the PLT should be included in that package.
>
> That sounds good to me.

bump?
_______________________________________________
erlang-patches mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-patches