Dependency report

Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Dependency report

Boost - Dev mailing list
I haven't run one of these in a while, so here it is.

http://pdimov.com/tmp/report-develop-6db78a0a6/module-overview.html
http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html
http://pdimov.com/tmp/report-develop-6db78a0a6/module-weights.html

We have one "supermodule" at level 5 and another at level 13.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
> http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html

One obvious low-hanging fruit here is moving <boost/next_prior.hpp> from
utility to iterator, breaking the utility -> iterator edge; I think this was
discussed recently?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
On 07/17/17 16:29, Peter Dimov via Boost wrote:
>> http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html
>
> One obvious low-hanging fruit here is moving <boost/next_prior.hpp> from
> utility to iterator, breaking the utility -> iterator edge; I think this
> was discussed recently?

I don't think it was (or may be I missed it).

Strictly speaking, boost::next/prior is not tied to iterators; it is
compatible with any type that has the necessary operators (e.g.
integers). Although the use case with iterators is probably the most
frequent.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Peter Dimov wrote:
> One obvious low-hanging fruit here is moving <boost/next_prior.hpp> from
> utility to iterator, breaking the utility -> iterator edge; I think this was
> discussed recently?

I posted a related thread last month during the discussion on
IteratorTraversalCategory-aware boost::advance (at that time,
I didn't know that boost::next/prior is not only for iterators),
but I got no response:

  [boost] [iterator][utility] Move utility/next_prior.hpp to Iterator module?
  https://lists.boost.org/Archives/boost/2017/06/236656.php

Regards,
Michel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
On 7/17/2017 6:11 PM, Michel Morin via Boost wrote:

> Peter Dimov wrote:
>> One obvious low-hanging fruit here is moving <boost/next_prior.hpp> from
>> utility to iterator, breaking the utility -> iterator edge; I think this was
>> discussed recently?
>
> I posted a related thread last month during the discussion on
> IteratorTraversalCategory-aware boost::advance (at that time,
> I didn't know that boost::next/prior is not only for iterators),
> but I got no response:
>
>    [boost] [iterator][utility] Move utility/next_prior.hpp to Iterator module?
>    https://lists.boost.org/Archives/boost/2017/06/236656.php

The change pushed by Andrey was to have iterator not use boost::prior
rather than to move boost/next_prior.hpp to iterator.

>
> Regards,
> Michel


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Andrey Semashev wrote:
> Strictly speaking, boost::next/prior is not tied to iterators; it is
> compatible with any type that has the necessary operators (e.g. integers).

Is it possible to deprecate the use of boost::next/prior for non-iterator types?
For non-iterator types, boost::next requires op+ or op+= (and similarly
boost::prior requires op- or op-=).
I think we can just use op+, unless the type has op+= but not op+.

Regards,
Michel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Edward Diener wrote:
> The change pushed by Andrey was to have iterator not use boost::prior rather
> than to move boost/next_prior.hpp to iterator.

Right, that change is to cut the cyclic dependency between boost/next_prior.hpp
and boost/iterator/reverse_iterator.hpp.

Andrey also pushed the change where boost/next_prior.hpp started to use
boost/iterator/advance.hpp.

Regards,
Michel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 07/18/17 03:44, Michel Morin via Boost wrote:
> Andrey Semashev wrote:
>> Strictly speaking, boost::next/prior is not tied to iterators; it is
>> compatible with any type that has the necessary operators (e.g. integers).
>
> Is it possible to deprecate the use of boost::next/prior for non-iterator types?

It is possible, but I'm not sure why we would do that. What is the
problem that we're trying to solve?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
Andrey Semashev wrote:
> On 07/18/17 03:44, Michel Morin via Boost wrote:
>> Is it possible to deprecate the use of boost::next/prior for non-iterator
>> types?
>
>
> It is possible, but I'm not sure why we would do that. What is the problem
> that we're trying to solve?

If Utility's dependency on Iterator is a problem,
the deprecation can help to move boost::next/prior to Iterator.
But the dependency is not a problem for me...

Regards,
Michel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
Michel Morin wrote:

> Andrey Semashev wrote:
> > On 07/18/17 03:44, Michel Morin via Boost wrote:
> >> Is it possible to deprecate the use of boost::next/prior for
> >> non-iterator types?
> >
> >
> > It is possible, but I'm not sure why we would do that. What is the
> > problem that we're trying to solve?
>
> If Utility's dependency on Iterator is a problem, the deprecation can help
> to move boost::next/prior to Iterator.

Yes please, let's move next_prior.hpp to Iterator while we're on this topic.
This dependency is not the end of the world by any means, but it would still
be a small step in the right direction.

It's true that next/prior are not limited to iterators, and that's fine,
there's no need to deprecate their use for non-iterators.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
New and improved reports here:

https://pdimov.github.io/boostdep-report/

> Yes please, let's move next_prior.hpp to Iterator while we're on this
> topic. This dependency is not the end of the world by any means, but it
> would still be a small step in the right direction.

utility -> iterator is the cause of a bunch of modules forming a tight group
at level 5:

https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5

which consequently makes all of them have 25 dependencies each:

https://pdimov.github.io/boostdep-report/develop/module-weights.html#weight:25


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
On 07/27/17 14:02, Peter Dimov via Boost wrote:
> New and improved reports here:
>
> https://pdimov.github.io/boostdep-report/

Looks great! It should really be run routinely along with source code
checks so that it is always actual and accessible through the website.

>> Yes please, let's move next_prior.hpp to Iterator while we're on this
>> topic. This dependency is not the end of the world by any means, but
>> it would still be a small step in the right direction.
>
> utility -> iterator is the cause of a bunch of modules forming a tight
> group at level 5:
>
> https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5

I don't quite understand what level means.

> which consequently makes all of them have 25 dependencies each:
>
> https://pdimov.github.io/boostdep-report/develop/module-weights.html#weight:25 

I don't quite remember how we moved headers between submodules in the
past. I think it required someone with commit rights to both submodules?

In any case, I don't mind if next_prior.hpp along with its tests and
docs is moved to Boost.Iterator, just let me know what I can do.

Also, if so requested, I can revert the commit that adds the dependency
(with the loss of the optimization it adds).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
Andrey Semashev wrote:

> > https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5
>
> I don't quite understand what level means.

Level is an artificial measure computed by placing all modules with no
dependencies at level 0, those that depend on level 0 on level 1, and so on.

> I don't quite remember how we moved headers between submodules in the
> past. I think it required someone with commit rights to both submodules?

In the past I moved headers along with their history by exporting the
commits to a text file and then applying that in the target repo, but I
think that's too much trouble for little worth. We could just remove it from
utility and commit it to iterator.

> In any case, I don't mind if next_prior.hpp along with its tests and docs
> is moved to Boost.Iterator, just let me know what I can do.

I see you're already on the "utility" team, I can add you to the "iterator"
team if Edward doesn't object?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
On 07/27/17 15:42, Peter Dimov via Boost wrote:

> Andrey Semashev wrote:
>
>> >
>> https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5 
>>
>>
>> I don't quite understand what level means.
>
> Level is an artificial measure computed by placing all modules with no
> dependencies at level 0, those that depend on level 0 on level 1, and so
> on.

But there are modules within level 5 that depend on other modules in
level 5. And also other modules that only depend on level 4 (e.g.
exception).

>> I don't quite remember how we moved headers between submodules in the
>> past. I think it required someone with commit rights to both submodules?
>
> In the past I moved headers along with their history by exporting the
> commits to a text file and then applying that in the target repo, but I
> think that's too much trouble for little worth. We could just remove it
> from utility and commit it to iterator.

I think history is worth retaining.

>> In any case, I don't mind if next_prior.hpp along with its tests and
>> docs is moved to Boost.Iterator, just let me know what I can do.
>
> I see you're already on the "utility" team, I can add you to the
> "iterator" team if Edward doesn't object?

I'd be ok with that.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
Andrey Semashev wrote:
> > Level is an artificial measure computed by placing all modules with no
> > dependencies at level 0, those that depend on level 0 on level 1, and so
> > on.
>
> But there are modules within level 5 that depend on other modules in level
> 5. And also other modules that only depend on level 4 (e.g. exception).

This is what happens when there are circular dependencies. When A depends on
B and B depends on A, it's not possible to make both A (level of B)+1 and B
(level of A)+1, so they are placed at the same level.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 7/27/2017 8:42 AM, Peter Dimov via Boost wrote:

> Andrey Semashev wrote:
>
>> >
>> https://pdimov.github.io/boostdep-report/develop/module-levels.html#level:5 
>>
>>
>> I don't quite understand what level means.
>
> Level is an artificial measure computed by placing all modules with no
> dependencies at level 0, those that depend on level 0 on level 1, and so
> on.
>
>> I don't quite remember how we moved headers between submodules in the
>> past. I think it required someone with commit rights to both submodules?
>
> In the past I moved headers along with their history by exporting the
> commits to a text file and then applying that in the target repo, but I
> think that's too much trouble for little worth. We could just remove it
> from utility and commit it to iterator.
>
>> In any case, I don't mind if next_prior.hpp along with its tests and
>> docs is moved to Boost.Iterator, just let me know what I can do.
>
> I see you're already on the "utility" team, I can add you to the
> "iterator" team if Edward doesn't object?

I do not object.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Peter Dimov wrote:
> In the past I moved headers along with their history by exporting the
> commits to a text file and then applying that in the target repo,

After the move, the original file is split into the two files:
one contains the actual code and the other is for the backward compatibility.
Did you transfer the history into only one of the two files?
Or can git allowed to transfer the history to both of the two split files?

This is an example of moving next_prior.hpp:

===============
Before the move
===============
[Boost.Iterator]
Does not contain anything related to next_prior.hpp.

[Boost.Utility]
Contains the following:
- include/boost/utility/next_prior.hpp

==============
After the move
==============
[Boost.Iterator module]
Contains the following:
- include/boost/iterator/next_prior.hpp
  * Contains the actual code for `next` and `prior`.
- include/boost/utility/next_prior.hpp
  * Just includes <boost/iterator/next_prior.hpp>.

[Boost.Utility module]
Does not contain anything related to next_prior.hpp.


Regards,
Michel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 7/17/17 5:04 AM, Peter Dimov via Boost wrote:
> I haven't run one of these in a while, so here it is.
>
> http://pdimov.com/tmp/report-develop-6db78a0a6/module-overview.html
> http://pdimov.com/tmp/report-develop-6db78a0a6/module-levels.html
> http://pdimov.com/tmp/report-develop-6db78a0a6/module-weights.html
>
> We have one "supermodule" at level 5 and another at level 13.

I like these reports and find them interesting.  But one thing would
make them much more useful to me.  Consider the following scenario:

I have a small app which uses the date_time library.  I would like to
know what boost modules I need to include.  I look on your charts, and
see that date-time has a primary dependency on the serialization
library.  This suggests that I need to include the serialization library
in my small app to make it work - which is actually untrue.  Now what
useful information has your report given me?

The problem of is that my small app includes only those headers from
date-time that it actually needs.  So a useful dependency report would
only follow those headers.  So.....

Could I ask for a feature enhancement for these tools (assuming they
don't already have it). Could I list a set of source files which would
constitute the "root" of the the dependency search.  Then I could

make my small app

run your tools with tool "small_app.cpp"

Get a list of boost submodules that I need to package/deliver with my
small app.

Seems like it would not be too difficult to add this facility and it
would be pretty useful. I would like to see it added tot he boost/tools
directory as a complement to bcp.

Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Michel Morin wrote:
> Peter Dimov wrote:
> > In the past I moved headers along with their history by exporting the
> > commits to a text file and then applying that in the target repo,
>
> After the move, the original file is split into the two files:
> one contains the actual code and the other is for the backward
> compatibility.
> Did you transfer the history into only one of the two files?

I moved the file as-is from the first repo to the other, as described here:

https://svn.boost.org/trac10/wiki/NewLibByRefactor

Then, assuming the result is include/boost/utility/next_prior.hpp in repo
iterator, I would rename it with `git mv` to
include/boost/iterator/next_prior.hpp. This ought to retain history. I would
then create the new forwarding file with the old name in a separate commit.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dependency report

Boost - Dev mailing list
Peter Dimov wrote:

> Michel Morin wrote:
>> After the move, the original file is split into the two files:
>> one contains the actual code and the other is for the backward
>> compatibility.
>> Did you transfer the history into only one of the two files?
>
>
> I moved the file as-is from the first repo to the other, as described here:
>
> https://svn.boost.org/trac10/wiki/NewLibByRefactor

Thanks for the link, I didn't know that such a page exists.


> Then, assuming the result is include/boost/utility/next_prior.hpp in repo
> iterator, I would rename it with `git mv` to
> include/boost/iterator/next_prior.hpp. This ought to retain history. I would
> then create the new forwarding file with the old name in a separate commit.

So `include/boost/iterator/next_prior.hpp ` retains history
and `include/boost/utility/next_prior.hpp ` is a new file.
That makes sense, thanks again.


Regards,
Michel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12
Loading...