Re: Fetching licensing info for all dependencies of a DUB project

[Christian Köstlin via Digitalmars-d-learn]

On 2022-06-28 14:34, Guillaume Piolat wrote:

On Monday, 27 June 2022 at 21:36:31 UTC, Christian Köstlin wrote:


I played around with the idea and came up with a small dub package, 
that is not (yet) uploaded to the dub registry.
Source is available at https://github.com/gizmomogwai/packageinfo, 
feedback very welcome.



I've done something similar not for licences but for code amount, to 
extract from a DUB project:

  - DUB packages used by project
  - source files used by project
  - and their LOC count

This is a D forums exclusive:
https://pastebin.com/RFbFCgR2

Keep your debt in check!


Interesting ... there is also dscanner that can count lines of code.
in another toy project of mine I create a dependency dot graph, might be 
good to collect all those things together ... there is also 
https://github.com/funkwerk/cogito that collect another metric of projects.

Re: DIP1000

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Wednesday, 29 June 2022 at 05:51:26 UTC, bauss wrote:
Not necessarily, especially if the fields aren't value types. 
You can have stack allocated "objects" with pointers to heap 
allocated memory (heap allocated "objects".)


Those are not fields, those are separate objects… The compiler 
knows which is a field (part of the object).


You can't, or rather you shouldn't have stack allocated fields 
within heap allocated "objects" however; as that will almost be 
guaranteed to lead to problems.


That is perfectly ok if you use RAII and manage life times.

Ex. from your example then even if the "node struct" you pass 
was allocated on the stack, then the memory the "next" pointer 
points to might not be allocated same place.


Unless I'm misunderstanding what you're trying to say.


You did :). If you look at the post I made in general about 
DIP1000 and flow typing you see that I annotate scope with a 
number to indicate life time ordering.


If you have `connect(int* a,int* b){a.next = b}` then the 
compiler can deduce that the signature with formal parameters 
should be `connect(scope!N(int*) a, scope_or_earlier!N(int*) b)`. 
The compiler then checks that the actual parameters at the call 
site are subtypes (same type or proper subtype).