Re: LDC 1.24.0

2020-12-13 Thread Jarrett Tierney via Digitalmars-d-announce

On Saturday, 24 October 2020 at 15:11:08 UTC, kinke wrote:

Glad to announce LDC 1.24 - some highlights:

- Based on D 2.094.1+.
- Support for LLVM 11. The prebuilt packages use v11.0.0, and 
the x86 packages newly include the LLVM backend for AMD GPUs.
- Experimental support for targeting macOS on 64-bit ARM. The 
macOS package includes prebuilt druntime/Phobos libraries for 
cross-compilation via `-mtriple=arm64-apple-macos`.


Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.24.0


Thanks to all contributors & sponsors!


Thank you ldc team. I know this is rather late to post the thank 
you, but wanted to let you know using your experimental support 
for targeting macOS on arm, I was actually able to build a native 
ldc for Mac m1. If anyone else wants to do the same here is what 
I did:


* Installed homebrew for m1 arm
* brew install llvm
* Downloaded your ldc Mac and used it as the bootstrap compiler
* Modified the ldc2.conf to fix the incorrect Xcode sysroot for 
the arm path (will file you a ticket for this)

* Cmake like in the wiki
* Modified build.ninja to get rid of some weird isysroot 
generations
* ninja build and ninja install and whooohoo I have a native arm 
compile tool chain for D


Re: An idea for commercial support for D

2015-01-05 Thread Jarrett Tierney via Digitalmars-d
As a user of D in a corporate environment and personal at home 
environment, I have to say this model won't work for me. In fact 
if this model were implemented, I would more than likely have to 
move my project to a different language because of it. Let me 
explain the issues I see here.


You've proposed a hybrid open and closed source model. Where 
certain segments of code (latest patches) are behind a per patch 
paywall. As a customer I don't want to have to pay for each bug 
fix in the compiler. If there is a bug in the language/compiler 
then I want it fixed. I shouldn't be charged to have the language 
I'm using work properly. It basically says to customers, here you 
can use this language for free, unless you want it to work 
properly, in which case you need to pay for each fix you need or 
wait till developers don't care about making money off a fix 
anymore.


This will also diminish the growth rate of D. I can tell you, it 
would be significantly harder for me to use D at my workplace if 
this model were in place. Managers are okay in letting me use D 
because its an open source project (minus the backend of DMD) and 
it doesn't cost them a cent. If all of the sudden I have to ask 
them to pay for fixes in order for my project to work, that makes 
it a different situation entirely. My company would also frown on 
the free option of waiting for fixes to pass out of the pay wall. 
Companies like actively supported projects. As such, companies 
(at least the one I work for) prefer either fully commercially 
supported languages (C# through VS) or fully open source.


Remember, that there are ways to provide commercial support 
without putting a paywall on using the language itself. What is 
really needed here is buy-in from corporations on the language. 
Having engineers from a company working on D would provide one 
form of commercial support. But this model is very difficult to 
find and the closest to it I've seen is Facebook's involvement 
with D. I agree having developers who are paid to work on D would 
be a great thing, but reaching that point is a very difficult 
road.


While I understand, that D needs some form of commercial support 
for some parties, there is also a stigma that the current model 
doesn't provide support. I've found to the contrary actually. I 
find the full open source model employed here, has a better 
support system than a lot of other commercial support models. The 
reason is the community, there is always someone around to answer 
a question. I find with most commercially supported models the 
development team can't be reached and you have to depend on your 
coworkers or friends who may know of a workaround (Microsoft 
model). Most of the time I see bugs get fixed fairly promptly for 
a compiler project despite the fragmented development that is 
inherent to open source projects.


I think commercial support for D really comes down to one of two 
situations in the future:


* A company decides to make a commercial D compiler that is 
closed source but compatible with phobos, etc. They fully support 
the compiler. (Doesn't necessarily mean they charge for the 
compiler itself, they could but they can also charge for support 
plans and/or a IDE tool).
* A company decides to invest engineers in working on the open 
source D compiler. Thus providing commercially supported 
developers to the project. (This would be a hybrid too, where the 
open source developers can still contribute and work but now 
there are a group of paid engineers working to advance the 
language as well).


On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote:
This is an idea I've been kicking around for a while, and given 
the need for commercial support for D, would perhaps work well 
here.


The notion is that individual developers could work on patches 
to fix bugs or add features to ldc/druntime/phobos then sell 
those closed patches to paying customers.  After enough time 
has passed, so that sufficient customers have adequately paid 
for the work or after a set time limit beyond that, the patch 
is open sourced and merged back upstream.  It would have to be 
ldc and not dmd, as the dmd backend is not open source and the 
gdc backend license doesn't allow such closed patches.


This works better than bounties because it avoids the tragedy 
of the commons problem inherent to open source and bounties, 
ie any user can just wait for some other contributor or any 
potential individual paying customer has an incentive to wait 
and let somebody else pay a bounty, then use the resulting work 
for free right away.  With this approach, non-paying users only 
get the resulting paid work after the work has been paid for 
and perhaps an additional delay after that.


Two big benefits come out of this approach.  Obviously, this 
would provide commercial support for paying customers, but the 
other big benefit is that it doesn't depend on some company 
providing that support.  A decentralized group of 

Re: 2 types of D users, both can live together happily if we adjust

2014-12-01 Thread Jarrett Tierney via Digitalmars-d
I think there have been many good points here. But I'd like to 
reiterate with any language of any size, it comes down to what 
you use in the language. Yes there are experimental features in D 
that are more influx than others, but depending on those features 
are really up to you and your team.


I think what you should do here, is look at what this D core 
means to you (what features you want to be core vs not) Then use 
that set to build the restrictions of how you code your project 
in D with. If you don't want to leverage the GC then design your 
code practices and project code around avoiding the GC and 
anything that uses it. To me it seems with due diligence, you can 
make your own D core by limiting what you use to just the small 
subset of features you trust. In the case of avoiding the GC, 
this requires learning what parts of phobos depend on the GC and 
what parts do not. I believe in some cases you can even leverage 
features of the D language to restrict some feature use (like 
enforcing the use of safe and pure).


I use D at a large tech corporation for an internal tool, and I 
can tell you overall I have not run into too many issues with D 
or its standard library. Usually when I find a feature I'm not 
sure about (stability or otherwise) I'll create a test D program 
and test it myself. Depending on the results I decide whether to 
use it or not.


I understand your points about support. When you are in a 
corporate environment of any size, support for your tools is a 
big deal. I got asked this many a time by my management when 
picking D for my project. The way I addressed the concern is more 
about focusing on quality vs quantity. Yes it would be nice to 
have D have a large set of contributors and maintainers, but no 
matter the amount of people, you have to have a good core set of 
contributors that are the experts. D is a perfect example of 
having this, with people like Walter and Andrei behind it (and 
many more). It is the nature of open source software, that leads 
it to the fragmented development model (engineers only working on 
the parts that interest them), but its also the project leads 
that pull everything together. I actually found that change and 
progress in the language for me inspires more faith in the 
language. Yes it introduces some noise in bug count and a 
developers workload in keeping up, but at the same time it keeps 
the language moving forward.


Hope this helps in some way

-Jarrett

On Saturday, 29 November 2014 at 17:26:30 UTC, Vic wrote:

On Friday, 28 November 2014 at 23:06:15 UTC, Mike wrote:
On Friday, 28 November 2014 at 20:20:55 UTC, ketmar via 
Digitalmars-d wrote:


this has an easy solution: just stick with the chosen D 
version: nobody forces anyone to upgrade.


Amen.


Here is the problem w/ that:
Lets stay that we use GDC (because of debugger) equivalent of D 
2.066(or whatever) for ~ year.


In essence, we check out of the D community. And when we come 
back, we find that the D community pool has not grown (due to 
some of the challenges we found). This means our project is not 
developed in an unsupported language, and we have to port.
(In forums I see maintainers talking about GC in core. I think 
that hooks for ref. counting should be in core, but move the 
implementation for the average case downstream. Plus many other 
things. To me, as a manager, figure out what your resources to 
be good at it, and no more).
I want to D, and the only way I see that is smaller D and the 
only way I see that is via a split so that the pool can grow.


Cheers,
Vic