www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - We need a community effort to maintain unmaintained dub packages,

reply mw <mingwu gmail.com> writes:
Hi,

I'm new here, try to start using D on my hobby projects, and I 
quickly run into issues when looking for supporting libraries.

I'm searching for a fixed point (decimal) type. On 
code.dlang.org, I found two packages having the functionalities 
that I need:

https://code.dlang.org/packages/decimal
https://code.dlang.org/packages/money

But I then run into issues with these packages (one has bug, and 
the other has compilation issues:
https://github.com/qznc/d-money/issues/11
https://github.com/rumbu13/decimal/issues/9)

And worse, it looks like both packages are no longer maintained 
by their original owners.

Then I found other people experienced the same difficulties, and 
started to re-invent those wheels, and the new packages are in 
0.0.x stage with limited functionalities.

I think we are wasting our community effort here. I'm wondering:


1) can we form a dub packages maintenance group, to take care of 
these no longer maintained packages


2) can we change the code.dlang.org to allow other users take 
over those packages, e.g. after 2 weeks no reply from the 
original owner:

https://github.com/rumbu13/decimal/issues/9#issuecomment-632843049

'''
I would be willing to take over and fix the package.
I have forked it already months ago.
The most important think would be to give me access on 
code.dlang.org, so users would find it.
'''

https://github.com/rumbu13/decimal/issues/8 (this issue has been 
more than half year now).


3) make the new "may-take-over-when-needed" policy explicit on 
https://code.dlang.org/, when people register new packages.


4) create a "dub packages maintenance" group in this forum, so 
people can discuss these issues.


Anything else? thoughts?
May 22 2020
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:

 I think we are wasting our community effort here. I'm wondering:


 1) can we form a dub packages maintenance group, to take care 
 of these no longer maintained packages


I believe this is the purpose of the dlang-community github 
organization:

https://github.com/dlang-community
May 22 2020
parent reply mw <mingwu gmail.com> writes:
On Friday, 22 May 2020 at 21:15:42 UTC, Paul Backus wrote:

 I believe this is the purpose of the dlang-community github 
 organization:

 https://github.com/dlang-community


Thanks for the link, can we add this link to 
https://code.dlang.org/

on each individual package's page, with the message:

If you found issues with this package, and it is no longer 
maintained and worth maintaining, please file an issue at:

https://github.com/dlang-community/discussions/issues


I'm adding the two packages I just found there.
May 22 2020
parent reply Seb <seb wilzba.ch> writes:
On Friday, 22 May 2020 at 21:35:45 UTC, mw wrote:

 On Friday, 22 May 2020 at 21:15:42 UTC, Paul Backus wrote:

 I believe this is the purpose of the dlang-community github 
 organization:

 https://github.com/dlang-community


 Thanks for the link, can we add this link to 
 https://code.dlang.org/

 on each individual package's page, with the message:

 If you found issues with this package, and it is no longer 
 maintained and worth maintaining, please file an issue at:

 https://github.com/dlang-community/discussions/issues


 I'm adding the two packages I just found there.


Well the capacities that dlang-community can maintain are limited 
as well, so I'm not sure whether it's a good idea to advertise it 
so openly as a "free service", but I agree that it currently has 
too little presence (and maintainers). We generally only move a 
package if there's a volunteer in dlang community that actually 
is interested in maintaining the library (though it's not hard to 
become such a volunteer).
May 22 2020
next sibling parent reply mw <mingwu gmail.com> writes:
On Friday, 22 May 2020 at 22:54:30 UTC, Seb wrote:

 , but I agree that it currently has too little presence (and 
 maintainers). We generally only move a package if there's a 
 volunteer in dlang community that actually is interested in 
 maintaining the library (though it's not hard to become such a 
 volunteer).


I can take one of the issue I found.  And  m3m0ry has express 
interest in take over the other one.

Just let me know the setup steps (any link somewhere?) on how to 
adopt the project to dlang-community, and someone who can do code 
review for me.

(I've noted on the issue ticket I filed.)
May 22 2020
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 22 May 2020 at 23:33:44 UTC, mw wrote:

 On Friday, 22 May 2020 at 22:54:30 UTC, Seb wrote:

 , but I agree that it currently has too little presence (and 
 maintainers). We generally only move a package if there's a 
 volunteer in dlang community that actually is interested in 
 maintaining the library (though it's not hard to become such a 
 volunteer).


 I can take one of the issue I found.  And  m3m0ry has express 
 interest in take over the other one.

 Just let me know the setup steps (any link somewhere?) on how 
 to adopt the project to dlang-community, and someone who can do 
 code review for me.

 (I've noted on the issue ticket I filed.)


The best is if the original project author(s) transfer the 
project to the dlang-community repo. Then they remain maintainers 
of the repo, but also other members of the dlang-community 
organization can contribute or invite other potential maintainers.

In case they are unavailable, the next option would be to create 
a fork, transfer it yourself and register it as new package on 
dlang.org.
Later down the road, if original author responds, you can move 
the original repo and delete the fork.
May 22 2020
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
I am happy for us to bring over a fixed-point data type, but not a money 
type.

Money requires external API access for get conversion rates ext.

A fixed point type at worst requires optimization for a given cpu.
Which is ok, very limited external dependencies needed to do that well.
May 22 2020
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 00:31:48 UTC, rikki cattermole wrote:

 I am happy for us to bring over a fixed-point data type, but 
 not a money type.

 Money requires external API access for get conversion rates ext.


That particular money package actually is very simple, it just 
implemented a fixed-point data type, and that's also what I need. 
(Ahh, even such a small thing is hard to find in dub, and this 
one is the most downloaded package in its kind with dub score 
4.0).


The other decimal package actually looks pretty decent:

https://github.com/rumbu13/decimal/issues/7

but, right now it has compilation and test errors:
https://github.com/rumbu13/decimal/issues


(sigh ..., suppose I want to use D in my work, how I can convince 
my company to use it if I cannot even get my personal hobby 
project done in D?)
May 22 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 23 May 2020 at 00:48:26 UTC, mw wrote:

 (sigh ..., suppose I want to use D in my work, how I can 
 convince my company to use it if I cannot even get my personal 
 hobby project done in D?)


Every language has unmaintained libraries. You could always fork 
and fix the errors.
May 22 2020
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 01:31:38 UTC, Mike Parker wrote:

 Every language has unmaintained libraries. You could always 
 fork and fix the errors.


Well, fork and fix is ok for personal project; but for the 
company, they will certainly say: why not choose a mature 
language with mature libraries? why not just use Java / Python / 
C++? why should we spend time fixing the libraries instead of 
getting our (functionality) work done?


I've some threads on this topic of industry use in the past:

April 24, 2012  How can D become adopted at my company?
https://forum.dlang.org/thread/exazrwacogokubvhjauh forum.dlang.org

June 05, 2016   Andrei's list of barriers to D adoption
https://forum.dlang.org/post/nj2mm1$1hun$1 digitalmars.com


it's almost 8 years now, is D's industry adoption picking up?
May 22 2020
next sibling parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:

 it's almost 8 years now, is D's industry adoption picking up?


Wow, it's more than 20 years now: quote

https://forum.dlang.org/post/nrhhnhocbsamkifkhzrd forum.dlang.org

"""
Hi Walter,

You had asked me a question that I have been thinking about for a 
couple years.

Your question from 2009 was, “How can D become adopted at my 
company?”


*** What makes a language successful? ***

I think Stroustrup’s answer is the best metric I’ve heard:  a 
language is successful if it is used.

"""
May 22 2020
parent mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 02:07:45 UTC, mw wrote:

 On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:
 Wow, it's more than 20 years now: quote


20 -- I mean since D started.
May 22 2020
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:

 Well, fork and fix is ok for personal project; but for the 
 company, they will certainly say: why not choose a mature 
 language with mature libraries? why not just use Java / Python 
 / C++? why should we spend time fixing the libraries instead of 
 getting our (functionality) work done?


If the library was in a complete and stable state when original 
the maintainer left, picking up it's maintenance is not that much 
of a trouble, assuming you only want to keep it compiling and to 
fix the most critical bugs. Even for a lone programmer it's worth 
considering, and more so for a company with many programmers.

This is because regressions due to library development is the 
main way the library can break code using it. If the development 
stops, so do the regressions, and code using it tends to keep 
working. The only problems left are:
1. breakage due to language updates
2. old bugs that the user has not happened to trigger.

Point one is much less work than dealing with regressions, and 
point two can usually be worked around, if fixing the library is 
too hard: You didn't trigger the feature before, so you can 
usually continue to avoid the usage that triggers the bug.
May 23 2020
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 10:23:09 UTC, Dukc wrote:

 On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:

 Well, fork and fix is ok for personal project; but for the 
 company, they will certainly say: why not choose a mature 
 language with mature libraries? why not just use Java / Python 
 / C++? why should we spend time fixing the libraries instead 
 of getting our (functionality) work done?


 If the library was in a complete and stable state when original 
 the maintainer left, picking up it's maintenance is not that 
 much of a trouble, assuming you only want to keep it compiling 
 and to fix the most critical bugs. Even for a lone programmer 
 it's worth considering, and more so for a company with many 
 programmers.


This is majority of the case we care about, i.e. fix the bug 
found in well-used unmaintained  packages.


But for industry usage, there is another side of the story, i.e 
accountability & company politics. The managers who can make 
decisions (together with the consequent responsibility) have to 
think about the worst scenario: what if the project missed the 
deadline? or even fail? Will s/he *bet* his/her job security or 
even career on a new language / library? Most managers sure 
won't. That's why companies always want to use *mature* language 
& libraries:

1) the project schedule can be more reliably estimated (without 
wasting extra time, detour to fix libraries bugs)

2) if the project delayed, or failed, at least nobody in the 
company can blame him/her choosed a new language & new libraries 
that caused the failure.
May 23 2020
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 23 May 2020 at 17:27:15 UTC, mw wrote:

 But for industry usage, there is another side of the story, i.e 
 accountability & company politics. The managers who can make 
 decisions (together with the consequent responsibility) have to 
 think about the worst scenario: what if the project missed the 
 deadline? or even fail? Will s/he *bet* his/her job security or 
 even career on a new language / library? Most managers sure 
 won't.


Your run-of-the-mill manager would think like that, I guess. That 
is why, as far as I know, D is used commercially in companies 
that are managed by tech people; People who can properly put a 
value on the advantages and disadvantages of using D, and 
consider its significance for their chances of success versus 
risk of failure.

— Bastiaan.
May 23 2020
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 18:45:25 UTC, Bastiaan Veelo wrote:

 On Saturday, 23 May 2020 at 17:27:15 UTC, mw wrote:

 But for industry usage, there is another side of the story, 
 i.e accountability & company politics. The managers who can 
 make decisions (together with the consequent responsibility) 
 have to think about the worst scenario: what if the project 
 missed the deadline? or even fail? Will s/he *bet* his/her job 
 security or even career on a new language / library? Most 
 managers sure won't.


 Your run-of-the-mill manager would think like that, I guess.


your use of word are exactly right ... in supporting *my* 
statement :-).
(I even don’t bother the personal attack in your words)


“run-of-the-mill”:    What does the idiom run of the mill mean?
run-of-the-mill. COMMON You use run-of-the-mill to describe 
something or someone that is ordinary and not at all exciting.


Common means, say 80 ~ 90% of the managers
In contrast, extraordinary (tech-savvy) means 10% of the managers

And my original statement:


 Will s/he *bet* his/her job security or even career on a new 
 language / library? Most managers sure won't.




Most == common == run-of-the-mill  :-)


But, are we betting on extraordinary managers to expanding the 
adoption of D.

Probably we are, and that explains how much we have achieved 
after 20 years of D.

And how much has the ordinary language like Java has achieved in 
the past 20 years.
You want *popular* adopt, then you have to think about what those 
“common” run-of-the-mill managers will choose :-)
May 23 2020
next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Saturday, 23 May 2020 at 19:12:14 UTC, mw wrote:

 And how much has the ordinary language like Java has achieved 
 in the past 20 years.


Sun played big role in Java's adoption. Most languages got 
popular because they had big corporate backer.
May 23 2020
next sibling parent mw <mingwu gmail.com> writes:
Speaking of ordinary vs extra-ordinary, do I need to mention the 
well known story of Paul Graham?

His startup, written in the most extraordinary programming 
language Lisp (IMHO), after sold to Yahoo, was rewritten to C++ 
and Perl:

https://discuss.fogcreek.com/joelonsoftware1/31402.html

This is another classic example of extraordinary-ness lose to 
ordinary-ness, unfortunately.


Frankly speaking, for my hobby project, I would want to use Lisp 
(I hope this won’t offend anybody here), but it’s really hard to 
get started without some good modern Lisp libraries for today’s 
IT infrastructure (hardware & software).

D is the 2nd on my language selection list. Language-wise, D 
certainly is superior to C++, and Java (among compiled languages 
that can offer decent performance). From my short D journey so 
far, I think if D’s supporting libraries can catchup with what 
the D language itself  has offered, D will have a much bright 
future.
May 23 2020
prev sibling parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 20:06:42 UTC, welkam wrote:

 On Saturday, 23 May 2020 at 19:12:14 UTC, mw wrote:

 And how much has the ordinary language like Java has achieved 
 in the past 20 years.


 Sun played big role in Java's adoption. Most languages got 
 popular because they had big corporate backer.



Then, who is the big corporate backer behind Python?

Well, I think it’s the community — the community who maintained 
those so many out-of-box, directly useable extraordinary 
packages: numpy, requests, pandas, keras, etc. to name just a 
few. Which are often sought after by other languages’ developers, 
and being simulated to keep the same interface, e.g. “what’s the 


Sure, behind the scene, the work is done by C, but it’s numPY who 
takes the credits.

D has such a native compatibility with C, do we have any library 
that come to the close of the popularity of numpy?


I would say, many times it’s the library packages that attract 
the people to use a particular  language, after all, not so many 
people are as enthusiastic about a particular programming 
language features as you and me or anyone on this forum.

Normally, people use a language — and most importantly the 
*libraries* — to get their job done. That *usage* determines 
which language becomes trendy, becomes popular.

I would say libraries can make a language, or destroy one.

Numpy has made Python’s fame. I think currently D is on the other 
side of this spectrum (after 20 years).
May 23 2020
next sibling parent reply Luis <luis.panadero gmail.com> writes:
On Sunday, 24 May 2020 at 01:56:13 UTC, mw wrote:

 I would say libraries can make a language, or destroy one.

 Numpy has made Python’s fame. I think currently D is on the 
 other side of this spectrum (after 20 years).


And Ruby had Rails...

The question is... we have something with these potential to 
become popular ?
May 23 2020
parent reply mw <mingwu gmail.com> writes:
On Sunday, 24 May 2020 at 06:57:01 UTC, Luis wrote:

 On Sunday, 24 May 2020 at 01:56:13 UTC, mw wrote:

 I would say libraries can make a language, or destroy one.

 Numpy has made Python’s fame. I think currently D is on the 
 other side of this spectrum (after 20 years).


 And Ruby had Rails...

 The question is... we have something with these potential to 
 become popular ?



D is late in the game, but still have potentials because of D's 
good performance and language features, e.g.

-- If vibe.d can catch up on the easy of use, and 
fast-prototyping with Django, Rails (performance-wise, we have 
trust in D), people may want to switch over to use it, after all 
compiled language ensures type safety for web services.

-- maybe numD? numpy is great, but because of the Python 
language's Global Interpreter Lock (GIL), people who want 
parallel data processing can only run on separate tasks via 
multiple processes, which sometimes is inconvenient when exchange 
information via shared memory is needed. This problem is 
*inherently unsolvable* in Python because of the GIL. If numD can 
offer everything numpy has offered, and plus parallel processing 
via multiple threads on multi-cores, it will have an edge.

-- the recent change  safe as default opt-in is good thing: 
without a  nogc phobos, nobody is going to write  system level 
software using D. I think this  safe change means the shift of 
D's focus from system software to application software. And I'm 
glad to see the the template project that dub generate starts 
with "app.d", which is the right direction for D.

-- anyone have more ideas to throw in?
May 24 2020
parent reply Luis <luis.panadero gmail.com> writes:
On Sunday, 24 May 2020 at 17:29:54 UTC, mw wrote:


 -- anyone have more ideas to throw in?


Pegged have a good potential. Nobody catches how powerful it's a 
parser library that can parse stuff on compilation time ?
May 24 2020
parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 24 May 2020 at 17:48:37 UTC, Luis wrote:


 Pegged have a good potential. Nobody catches how powerful it's 
 a parser library that can parse stuff on compilation time ?


Bastiaan Veelo at DConf 2017: Extending Pegged to Parse Another 
Programming Language
https://www.youtube.com/watch?v=NoAJziYZ4qs&feature=youtu.be
May 24 2020
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Sunday, 24 May 2020 at 01:56:13 UTC, mw wrote:

 On Saturday, 23 May 2020 at 20:06:42 UTC, welkam wrote:



 Then, who is the big corporate backer behind Python?

 Well, I think it’s the community — the community who maintained 
 those so many out-of-box, directly useable extraordinary 
 packages: numpy, requests, pandas, keras, etc. to name just a 
 few. Which are often sought after by other languages’ 
 developers, and being simulated to keep the same interface, 


 Sure, behind the scene, the work is done by C, but it’s numPY 
 who takes the credits.



 I would say, many times it’s the library packages that attract 
 the people to use a particular  language, after all, not so 
 many people are as enthusiastic about a particular programming 
 language features as you and me or anyone on this forum.

 Normally, people use a language — and most importantly the 
 *libraries* — to get their job done. That *usage* determines 
 which language becomes trendy, becomes popular.

 I would say libraries can make a language, or destroy one.

 Numpy has made Python’s fame. I think currently D is on the 
 other side of this spectrum (after 20 years).


I couldn't say better. You've said it all.

I use Node.Js MORE not because JavaScript is technically the best 
language out there, its because it gets things done. Mostly the 
packages on NPM. Its what I care about...and I can confidently 
say that for a lot of devs using it...its why I came to it, its 
why I stayed. How perfect or technically solid a language is 
doesn't matter to run-the-mill devs (and they are the 
majority...80%-90%), its the ecosystem of RELIABLE tools and 
libraries/packages to get job done.

Somehow we haven't figured this out. We have the most brilliant 
engineers doing the impossible here but that alone is not enough. 
More devs means more contributors...especially for those less 
technical stuff (arguably the majority of our problems)
May 24 2020
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 23 May 2020 at 19:12:14 UTC, mw wrote:

 On Saturday, 23 May 2020 at 18:45:25 UTC, Bastiaan Veelo wrote:

 On Saturday, 23 May 2020 at 17:27:15 UTC, mw wrote:

 But for industry usage, there is another side of the story, 
 i.e accountability & company politics. The managers who can 
 make decisions (together with the consequent responsibility) 
 have to think about the worst scenario: what if the project 
 missed the deadline? or even fail? Will s/he *bet* his/her 
 job security or even career on a new language / library? Most 
 managers sure won't.


 Your run-of-the-mill manager would think like that, I guess.


 your use of word are exactly right ... in supporting *my* 
 statement :-).


Indeed, I am supporting your statement.


 (I even don’t bother the personal attack in your words)


No attack intended!


 “run-of-the-mill”:    What does the idiom run of the mill mean?
 run-of-the-mill. COMMON You use run-of-the-mill to describe 
 something or someone that is ordinary and not at all exciting.


 Common means, say 80 ~ 90% of the managers
 In contrast, extraordinary (tech-savvy) means 10% of the 
 managers

 And my original statement:


 Will s/he *bet* his/her job security or even career on a new 
 language / library? Most managers sure won't.




 Most == common == run-of-the-mill  :-)


Yes, that is what I mean. It is just my observation.


 But, are we betting on extraordinary managers to expanding the 
 adoption of D.

 Probably we are, and that explains how much we have achieved 
 after 20 years of D.


I don’t think there’s much betting being done around here. We 
just gather around a shared treasure and each of us (individuals 
and companies) invest in it as much as we can and want to. Would 
it be cool if using D would be a no-brainer for every manager? 
Probably, but getting there with volunteers only is unlikely. 
Personally I am happy that D is still around even after 20 years, 
so that I can use it professionally. And I made a considerable 
investment to make it that way.

Some people are disappointed that D is not as widely adopted as 
they would like it to be, and somehow feel the need to put the 
blame somewhere. I don’t see the point in that, I’d say just use 
it if you want to, and make it better if you want to.

Cheers, and welcome!

— Bastiaan.
May 24 2020
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 24 May 2020 at 11:13:03 UTC, Bastiaan Veelo wrote:

 On Saturday, 23 May 2020 at 19:12:14 UTC, mw wrote:

 On Saturday, 23 May 2020 at 18:45:25 UTC, Bastiaan Veelo wrote:

 Your run-of-the-mill manager would think like that, I guess.





 (I even don’t bother the personal attack in your words)


 No attack intended!


Ah now I see how my words may have come out hostile. I was not 
insinuating anything about _your_ manager. I meant something like 
"the typical manager". I thought that's how the phrase is 
typically used ("Your run-of-the-mill ...") but I'm not a native 
English speaker.

-- Bastiaan.
May 24 2020
parent mw <mingwu gmail.com> writes:
On Sunday, 24 May 2020 at 16:26:33 UTC, Bastiaan Veelo wrote:

 Ah now I see how my words may have come out hostile. I was not 
 insinuating anything about _your_ manager. I meant something 
 like "the typical manager". I thought that's how the phrase is 
 typically used ("Your run-of-the-mill ...") but I'm not a 
 native English speaker.


No worries, neither am I.
May 24 2020
prev sibling parent reply Jan =?UTF-8?B?SMO2bmln?= <hrominium gmail.com> writes:
On Saturday, 23 May 2020 at 00:48:26 UTC, mw wrote:

 The other decimal package actually looks pretty decent:


For this reason I have started my own extremely simple fixedpoint 
type:
https://github.com/m3m0ry/fixedpoint
https://code.dlang.org/packages/fixedpoint

For me it would be great, if you use it for a personal project, 
since I am as well.


As for the decimal package. I am currently trying to get the 
"rights" to it, so I can fix it.

The problem with decimal types is, that one solution is not 
enough. There are many possibilities how to achieve it, each of 
them having its own pros and cons.
May 22 2020
parent Jan =?UTF-8?B?SMO2bmln?= <hrominium gmail.com> writes:
On Saturday, 23 May 2020 at 06:57:32 UTC, Jan Hönig wrote:

 For this reason I have started my own extremely simple


I see you have found it :)
May 22 2020
prev sibling next sibling parent reply Luis <luis.panadero gmail.com> writes:
On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:

 And worse, it looks like both packages are no longer maintained 
 by their original owners.

 Then I found other people experienced the same difficulties, 
 and started to re-invent those wheels, and the new packages are 
 in 0.0.x stage with limited functionalities.

 I think we are wasting our community effort here. I'm wondering


Because this, I forked two small packages and get it under my 
wing, with the self-compromise that at least I will keep it 
working on future versions of D. However, I published they with 
different names and changing the module name. Something that 
should be totally unnecessary.

And there are many packages with the same problem on the wild.
May 23 2020
parent reply mw <mingwu gmail.com> writes:
On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:

 Because this, I forked two small packages and get it under my 
 wing, with the self-compromise that at least I will keep it 
 working on future versions of D. However, I published they with 
 different names and changing the module name. Something that 
 should be totally unnecessary.

 And there are many packages with the same problem on the wild.



Right, people forked & fixed, but the fix cannot be contributed 
back to the D community.

Other users are still getting the original buggy version from 
dub, and don't have an easy way to find new patches.

So the main blocker is to get the write permission (of the 
unmaintained packages) of the dub system, this will solve lots of 
these problems.

Or we should setup a new policy that any new dub packages should 
give write permission to dlang-community by default.
May 23 2020
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 23 May 2020 at 17:10:27 UTC, mw wrote:

 On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:

 Because this, I forked two small packages and get it under my 
 wing, with the self-compromise that at least I will keep it 
 working on future versions of D. However, I published they 
 with different names and changing the module name. Something 
 that should be totally unnecessary.

 And there are many packages with the same problem on the wild.



 Right, people forked & fixed, but the fix cannot be contributed 
 back to the D community.

 Other users are still getting the original buggy version from 
 dub, and don't have an easy way to find new patches.

 So the main blocker is to get the write permission (of the 
 unmaintained packages) of the dub system, this will solve lots 
 of these problems.

 Or we should setup a new policy that any new dub packages 
 should give write permission to dlang-community by default.


How about putting every packages under dlang-community under a 
repo maintained by community so anyone else can accept pull 
request.

If anyone else starts another decimal package, it'll also end up 
the same way most likely.

It's about time we have packages regarded as core with the 
community in charge...so we can direct contributions to them. 
Every fix gets submitted there...
May 23 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 23 May 2020 at 17:46:42 UTC, aberba wrote:

 On Saturday, 23 May 2020 at 17:10:27 UTC, mw wrote:

 On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:

 Because this, I forked two small packages and get it under my 
 wing, with the self-compromise that at least I will keep it 
 working on future versions of D. However, I published they 
 with different names and changing the module name. Something 
 that should be totally unnecessary.

 And there are many packages with the same problem on the wild.



 Right, people forked & fixed, but the fix cannot be 
 contributed back to the D community.

 Other users are still getting the original buggy version from 
 dub, and don't have an easy way to find new patches.

 So the main blocker is to get the write permission (of the 
 unmaintained packages) of the dub system, this will solve lots 
 of these problems.

 Or we should setup a new policy that any new dub packages 
 should give write permission to dlang-community by default.


 How about putting every packages under dlang-community under a 
 repo maintained by community so anyone else can accept pull 
 request.

 If anyone else starts another decimal package, it'll also end 
 up the same way most likely.

 It's about time we have packages regarded as core with the 
 community in charge...so we can direct contributions to them. 
 Every fix gets submitted there...


The community here is very week. I've also talked to lack of 
focus on community building. Every open source endure needs a 
strong community to make things happen under a collective effort. 
Until there's official push and dedication to making that happen, 
we'll also be overruns by things to do.
May 23 2020
parent aberba <karabutaworld gmail.com> writes:
On Saturday, 23 May 2020 at 17:49:59 UTC, aberba wrote:






I meant...

The community here has always been very week. I've often talked 
about lack of focus on community building. Every open source 
endeavor needs a strong community to make things happen under a 
collective effort. Until there's official push and dedication to 
making that happen, we'll always be overrun by things to do.

The more the hands on deck, the less it remains for each one to 
have to do.

I'm having a love and hate relationship with D right now.



 May 23 2020



prev sibling  parent  Basile B. <b2.temp gmx.com>  writes:


On Saturday, 23 May 2020 at 17:10:27 UTC, mw wrote:

 On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:

 Because this, I forked two small packages and get it under my 
 wing, with the self-compromise that at least I will keep it 
 working on future versions of D. However, I published they 
 with different names and changing the module name. Something 
 that should be totally unnecessary.

 And there are many packages with the same problem on the wild.



 Right, people forked & fixed, but the fix cannot be contributed 
 back to the D community.

 Other users are still getting the original buggy version from 
 dub, and don't have an easy way to find new patches.

 So the main blocker is to get the write permission (of the 
 unmaintained packages) of the dub system, this will solve lots 
 of these problems.

 Or we should setup a new policy that any new dub packages 
 should give write permission to dlang-community by default.


https://github.com/dlang-community was created for that.
https://github.com/dlang-community/discussions#adoption-guidelines.



 May 23 2020



prev sibling next sibling parent  Rumbu <rumbu rumbu.ro>  writes:


On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:

 Hi,

 I'm new here, try to start using D on my hobby projects, and I 
 quickly run into issues when looking for supporting libraries.

 I'm searching for a fixed point (decimal) type. On 
 code.dlang.org, I found two packages having the functionalities 
 that I need:

 https://code.dlang.org/packages/decimal
 https://code.dlang.org/packages/money

 But I then run into issues with these packages (one has bug, 
 and the other has compilation issues:
 https://github.com/qznc/d-money/issues/11
 https://github.com/rumbu13/decimal/issues/9)

 And worse, it looks like both packages are no longer maintained 
 by their original owners.

 Then I found other people experienced the same difficulties, 
 and started to re-invent those wheels, and the new packages are 
 in 0.0.x stage with limited functionalities.

 I think we are wasting our community effort here. I'm wondering:


 1) can we form a dub packages maintenance group, to take care 
 of these no longer maintained packages


 2) can we change the code.dlang.org to allow other users take 
 over those packages, e.g. after 2 weeks no reply from the 
 original owner:

 https://github.com/rumbu13/decimal/issues/9#issuecomment-632843049

 '''
 I would be willing to take over and fix the package.
 I have forked it already months ago.
 The most important think would be to give me access on 
 code.dlang.org, so users would find it.
 '''

 https://github.com/rumbu13/decimal/issues/8 (this issue has 
 been more than half year now).


 3) make the new "may-take-over-when-needed" policy explicit on 
 https://code.dlang.org/, when people register new packages.


 4) create a "dub packages maintenance" group in this forum, so 
 people can discuss these issues.


 Anything else? thoughts?


I am back, if you need me (ref decimal). Explanation for the 
failed test is here:
https://github.com/rumbu13/decimal/issues/9#issuecomment-767776857



 Jan 26 2021



prev sibling  parent reply Murilo <murilomiranda92 hotmail.com>  writes:


On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:

 Hi,

 I'm new here, try to start using D on my hobby projects, and I 
 quickly run into issues when looking for supporting libraries.
 Anything else? thoughts?


I think there should be one universal library that should contain 
modules for everything, that way all work would be done with only 
one library, that would make it more organized and maintainable 
since there would be only one library to take care of.



 Jan 27 2021



 next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com>  writes:


On Wednesday, 27 January 2021 at 18:18:51 UTC, Murilo wrote:

 On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:

 Hi,

 I'm new here, try to start using D on my hobby projects, and I 
 quickly run into issues when looking for supporting libraries.
 Anything else? thoughts?


 I think there should be one universal library that should 
 contain modules for everything, that way all work would be done 
 with only one library, that would make it more organized and 
 maintainable since there would be only one library to take care 
 of.


https://xkcd.com/927/ ;)



 Jan 27 2021



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Wed, Jan 27, 2021 at 08:57:30PM +0000, Petar via Digitalmars-d wrote:

 On Wednesday, 27 January 2021 at 18:18:51 UTC, Murilo wrote:

 On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:

 Hi,
 
 I'm new here, try to start using D on my hobby projects, and I
 quickly run into issues when looking for supporting libraries.
 Anything else? thoughts?


 
 I think there should be one universal library that should contain
 modules for everything, that way all work would be done with only
 one library, that would make it more organized and maintainable
 since there would be only one library to take care of.


 
 https://xkcd.com/927/ ;)


Not to mention, one giant, monolithic library that tries to do
everything will be a nightmare to maintain; after a certain point you
couldn't change anything without breaking or becoming incompatible with
other parts of the library, and it would be a slog just to get a simple
change implemented.

My inclination these days is small, self-contained libraries with few
(preferably no) dependencies. Adam Ruppe's arsd library is an excellent
example.  With a small, independent codebase you can move much faster
without being held back by large-scale considerations inevitable in a
large codebase.


T

-- 
PNP = Plug 'N' Pray



 Jan 27 2021



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Wednesday, 27 January 2021 at 22:47:56 UTC, H. S. Teoh wrote:

 Not to mention, one giant, monolithic library that tries to do 
 everything [...] Adam Ruppe's arsd library is an excellent 
 example.


fixed that for you

it is kind ironic, i have like 70 diverse modules, so it is kinda 
a "giant" library, but since I'm so strict on modular 
independence (even to the point of copy/pasting code in a few 
places) it is more like 50 "libraries" in one.

(I kinda hate the term library btw. A real world library is a big 
building with a bunch of random books. The librarian doesn't 
write all the books and most the books have nothing to do with 
each other. They are just made available there. That's the way I 
see the arsd lib - a "library" made up of a bunch of individual 
books from various sources. And my main job as librarian is to 
just ensure they stay in condition that people can check them out.

and of course I write like 2/3 of them myself too lol. But a 
surprising number of the modules in there actually aren't written 
by me at all.)



 Jan 27 2021



  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Wed, Jan 27, 2021 at 11:38:28PM +0000, Adam D. Ruppe via Digitalmars-d wrote:

 On Wednesday, 27 January 2021 at 22:47:56 UTC, H. S. Teoh wrote:

 Not to mention, one giant, monolithic library that tries to do
 everything [...] Adam Ruppe's arsd library is an excellent example.


 
 fixed that for you


lol... fine, you got me there. :-D



 it is kind ironic, i have like 70 diverse modules, so it is kinda a
 "giant" library, but since I'm so strict on modular independence (even
 to the point of copy/pasting code in a few places) it is more like 50
 "libraries" in one.


I think this is the key.

Over the years I've come to question the dogma of code reuse, esp. when
it comes in the form of wanton dependencies, each of which in turn comes
with its own set of dependencies, ad nauseaum.  It's basically the
dependency hell edition of the good work vs great work conundrum. You
can't argue that dependencies are bad, because it doesn't make sense to
write everything from scratch yourself.  But each dependency begets more
dependencies.  The result is that the simplest of tasks requires pulling
in a disproportionate number of dependencies, 90% of which you don't
actually need.  It's very telling that figuring out your way in this
tangled web of dependencies is an NP-complete problem.  IMNSHO, solving
NP-complete problems should be what your program *does* for the user,
not what *you* need to do in order to be able to compile your program in
the first place!

A *great* dependency is one that does *not* itself pull in more
dependencies.  The best is that it's a self-contained unit that you can
literally just copy into your source tree and it Just Works(tm) with no
further fuss or muss.  No need for bloated heavyweight package managers
that require gobs of disk space and RAM to solve NP-complete problems
just so your program can be encumbered with an exponential number of
dependencies.  Just drop the danged file into your workspace and start
using it.  Nimble, flexible, and free of needless encumbrances.  The way
it should be.



 (I kinda hate the term library btw. A real world library is a big
 building with a bunch of random books. The librarian doesn't write all
 the books and most the books have nothing to do with each other. They
 are just made available there. That's the way I see the arsd lib - a
 "library" made up of a bunch of individual books from various sources.
 And my main job as librarian is to just ensure they stay in condition
 that people can check them out.


[...]

That actually makes more sense than the way we usually use the word
"library". :-D


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom



 Jan 28 2021



prev sibling  parent reply sighoya <sighoya gmail.com>  writes:


On Wednesday, 27 January 2021 at 18:18:51 UTC, Murilo wrote:

 I think there should be one universal library that should 
 contain modules for everything, that way all work would be done 
 with only one library, that would make it more organized and 
 maintainable since there would be only one library to take care 
 of.


And the usage of only one language would also unify the power of 
maintenance and organization, but which language should be the 
one... :)



 Jan 27 2021



  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Wed, Jan 27, 2021 at 10:02:15PM +0000, sighoya via Digitalmars-d wrote:

 On Wednesday, 27 January 2021 at 18:18:51 UTC, Murilo wrote:

 I think there should be one universal library that should contain
 modules for everything, that way all work would be done with only
 one library, that would make it more organized and maintainable
 since there would be only one library to take care of.


 
 And the usage of only one language would also unify the power of
 maintenance and organization, but which language should be the one...
 :)


D of course! ;-)


T

-- 
There is no gravity. The earth sucks.



 Jan 27 2021