Re: dmd front end now switched to Boost license
On 6/13/2014 8:15 PM, Mathias LANG wrote: On Friday, 13 June 2014 at 11:31:10 UTC, Dmitry Olshansky wrote: 13-Jun-2014 04:31, Walter Bright пишет: https://github.com/D-Programming-Language/dmd/pull/3655 Heh, I had been under the impression was already Boost. :P It's probably nice to have less restrictive license, but what we aim to achieve with that? Make commercial companies contribute to DMD more freely? There is no problem even with GPL. Let them build and sell their own products out of DMDFE? Highly unlikely to be a profitable anyway, and we'd better get back the patches. Wild guess: DMD in fedora, debian et al. repositories ? I doubt it. First, it's the backend that's not technically OSI, frontend was (apparently) GPL. Second, I can't imagine any Linux distro rejecting GPL - they'd have to boot the kernel and core utils, too. Boost has kinda become the favored D license anyway, Phobos etc., so it probably has a lot to do with that. Kinda weird to have the compiler and stdlib under different licenses.
Re: dmd front end now switched to Boost license
On Saturday, 14 June 2014 at 06:07:08 UTC, Nick Sabalausky wrote: I doubt it. First, it's the backend that's not technically OSI, frontend was (apparently) GPL. Second, I can't imagine any Linux distro rejecting GPL - they'd have to boot the kernel and core utils, too. Actually, the frontend was dual-licensed under the Artistic license and the GPL and dmd binaries were provided under the former, as the GPL doesn't allow linking against a non-GPL backend. The GPL alternative was likely for gdc to link the frontend against the GPL'd gcc backend.
Re: DMD 2.066 Alpha
On Thursday, 12 June 2014 at 18:25:36 UTC, Andrei Alexandrescu wrote: On 6/12/14, 6:34 AM, Dicebot wrote: It was decided and 100% certain - virtual is not going in. Need to remove it from DMD before this release is out. Yes please. -- Andrei Since we didn't seem to have a pull request for removing the attribute: https://github.com/D-Programming-Language/dmd/pull/3663 David
Re: dmd front end now switched to Boost license
14-Jun-2014 04:46, Walter Bright пишет: On 6/13/2014 4:31 AM, Dmitry Olshansky wrote: It's probably nice to have less restrictive license, but what we aim to achieve with that? I do not want to come across as rude but from pragmatic standpoint it's not interesting. I'm not opposing it (after all I agreed to change it), I just don't see any valuable gains. 1. Boost is the least restrictive license This gains nothing in and by itself. 4 speaks of potential adv, which realistically is not something we desperately want. Maybe as a proactive move, that I could understand. 2. Minimize friction for adopting D Let's not deluge ourselves, it does nothing to do that unlike many other things. Changing license of G++ frontend to boost won't make people adopt C++ any faster. The only place of friction is backend, and opening FE for commerce doesn't help it. 3. Harmonization with usage of Boost in the runtime library In other words simplify licensing, but again compiler and runtime library do not have to have anything in common. There is no issue to begin with. 4. Allow commercial use of DMDFE (so what if someone does? It'll drive even more adoption of D!) The only strictly valid point. Making commercial compilers and tools on D front-end is the only solid result this move enables. 5. Boost is well known and accepted All of licenses are well known. Again by itself it's not interesting, it won't make dmd any more easy to get into FOSS distros. -- Dmitry Olshansky
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Thursday, 12 June 2014 at 16:42:38 UTC, Dmitry Olshansky wrote: It's always nice to ask something on D NG, so many good answers I can hardly choose whom to reply ;) So this is kind of broadcast. Yes, the answer seems spot on - reflection! But allow me to retort. I'm not talking about completely stand-alone generator. Just as well generator tool could be written in D using the same exact sources as your D program does. Including the static introspection and type-awareness. Then generator itself is a library + an invocation script in D. The Q is specifically of CTFE in this scenario, including not only obvious shortcomings of design, but fundamental ones of compilation inside of compilation. Unlike proper compilation is has nothing persistent to back it up. It feels backwards, a bit like C++ TMP but, of course, much-much better. 1) Reflection. It is less of an issue for pure DSL solutions because those don't provide any good reflection capabilities anyway, but other code generation approaches have very similar problems. By doing all code generation in separate build step you potentially lose many of guarantees of keeping various parts of your application in sync. Use the same sources for the generator. In essence all is the same, just relying on separate runs and linkage, not mixin. Necessary hooks to link to later could indeed be generated with a tiny bit of CTFE. Yes, deeply embedded stuff might not be that easy. The scope and damage is smaller though. 2) Moving forward. You use traditional reasoning of DSL generally being something rare and normally stable. This fits most common DSL usage but tight in-language integration D makes possible brings new opportunities of using DSL and code generation casually all other your program. Well, I'm biased by heavy-handed ones. Say I have a (no longer) secret plan of doing a next-gen parser generator in D. Needless to say swaths of non-trivial code generation. I'm all for embedding nicely but I see very little _practical_ gains in CTFE+mixin here EVEN if CTFE wouldn't suck. See the point above about using the same metadata and types as the user application would. Consider something like REST API generator I have described during DConf. There is different code generated in different contexts from same declarative description - both for server and client. Right now simple fact that you import very same module from both gives solid 100% guarantee that API usage between those two programs stays in sync. In your proposed scenario there will be two different generated files imported by server and client respectively. Tiny typo in writing your build script will result in hard to detect run-time bug while code itself still happily compiles. You may keep convenience but losing guarantees hurts a lot. To be able to verify static correctness of your program / group of programs type system needs to be aware how generated code relates to original source. Also this approach does not scale. I can totally imagine you doing it for two or three DSL in single program, probably even dozen. But something like 100+? Huge mess to maintain. According to my experience all builds systems are incredibly fragile beasts, trusting them something that impacts program correctness and won't be detected at compile time is just too dangerous. I totally expect programming culture to evolve to the point where something like 90% of all application code is being generated in typical project. D has good base for promoting such paradigm switch and reducing any unnecessary mental context switches is very important here. This was pretty much the point I was trying to make with my DConf talk ( and have probably failed :) ) I liked the talk, but you know ... 4th or 5th talk with CTFE/mixin I think I might have been distracted :) More specifically this bright future of 90%+ concise DSL driven programs is undermined by the simple truth - no amount of improvement in CTFE would make generators run faster then optimized standalone tool invocation. The tool (library written in D) may read D metadata just fine. I heard D builds times are important part of its adoption so... Adoption - yes. Production usage - less so (though still important). Difference between 1 second and 5 seconds is very important. Between 10 seconds and 1 minute - not so much. JIT will be probably slower than stand-alone generators but not that slower. It might solve most of _current_ problems, but I foresee fundamental issues of no global state in CTFE that in say 10 years from now would look a lot like `#include` in C++. I hope 10 years ago from now we will consider having global state in RTFE stone age relict :P A major one is there is no way for compiler to not recompile generated code as it has no knowledge of how it might have changed from the previous run. Why can't we merge basic build system functionality akin to
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On 6/14/14, 8:05 AM, Dicebot wrote: Adoption - yes. Production usage - less so (though still important). Difference between 1 second and 5 seconds is very important. Between 10 seconds and 1 minute - not so much. Wait, what? -- Andrei
Re: dmd front end now switched to Boost license
Nick Sabalausky, el 14 de June a las 02:06 me escribiste: It's probably nice to have less restrictive license, but what we aim to achieve with that? Make commercial companies contribute to DMD more freely? There is no problem even with GPL. Let them build and sell their own products out of DMDFE? Highly unlikely to be a profitable anyway, and we'd better get back the patches. Wild guess: DMD in fedora, debian et al. repositories ? I doubt it. First, it's the backend that's not technically OSI, frontend was (apparently) GPL. Second, I can't imagine any Linux distro rejecting GPL - they'd have to boot the kernel and core utils, too. Boost has kinda become the favored D license anyway, Phobos etc., so it probably has a lot to do with that. Kinda weird to have the compiler and stdlib under different licenses. Not really, the standard library is included into user code (because of the templates), and that's the reason why it needs to be under a very permissive license. The compiler, on the other hand, doesn't, and one could agree is good to force people wanting to build products using the compiler FE to contribute changes back. I guess the main purpose of this is encourage proprietary tools based on the FE, but if that's the case, there are better licenses for this, like the LGPL, which let proprietary tools to link code against the DMD FE without having to release their code under a free license. With Boost, anyone can create a tool with DMD FE, improve the DMD FE in the process and distribute the modified DMD FE without offering the source code of the DMD FE to the received, which kind of sucks. In practice I guess not many people would do that, but I think it would have been a nice gesture to ask contributors how they feel about this license change, even when I think technically you are somehow giving up your rights to Digital Mars when contributing to DMDFE and thus they can do whatever they want with the code, legally speaking. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Every 5 minutes an area of rainforest the size of a foot ball field Is eliminated
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On Saturday, 14 June 2014 at 15:25:11 UTC, Andrei Alexandrescu wrote: On 6/14/14, 8:05 AM, Dicebot wrote: Adoption - yes. Production usage - less so (though still important). Difference between 1 second and 5 seconds is very important. Between 10 seconds and 1 minute - not so much. Wait, what? -- Andrei If build time becomes long enough that it forces you to switch the mental context, it is less important how long it takes - you are much likely to do something else and return to it later. Of course it can also get to famous C++ hours of build time which is next level of inconvenience :) But reasonably big and complicated project won't build in 5 seconds anyway (even with perfect compiler), so eventually pure build time becomes less of a selling point. Still important but not _that_ important.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
14-Jun-2014 19:05, Dicebot пишет:
On Thursday, 12 June 2014 at 16:42:38 UTC, Dmitry Olshansky wrote:
[snip]
Well, I'm biased by heavy-handed ones. Say I have a (no longer) secret
plan of doing a next-gen parser generator in D. Needless to say swaths
of non-trivial code generation. I'm all for embedding nicely but I see
very little _practical_ gains in CTFE+mixin here EVEN if CTFE wouldn't
suck. See the point above about using the same metadata and types as
the user application would.
Consider something like REST API generator I have described during
DConf. There is different code generated in different contexts from same
declarative description - both for server and client. Right now simple
fact that you import very same module from both gives solid 100%
guarantee that API usage between those two programs stays in sync.
But let's face it - it's a one-time job to get it right in your favorite
build tool. Then you have fast and cached (re)build. Comparatively costs
of CTFE generation are paid in full during _each_ build.
In your proposed scenario there will be two different generated files
imported by server and client respectively. Tiny typo in writing your
build script will result in hard to detect run-time bug while code
itself still happily compiles.
Or a link error if we go a hybrid path where the imported module is
emitting declarations/hooks via CTFE to be linked to by the proper
generated code. This is something I'm thinking that could be a practical
solution.
I.e. currently to get around wasting cycles again and again:
module a;
bool verify(string s){
static re = ctRegex!; return match(s, re);
}
//
module b;
import a;
void foo(){
...
verify(blah);
...
}
vs would-be hybrid approach:
module gen_re;
void main() //or wrap it in tiny template mixin
{
generateCtRegex(
//all patterns
);
}
module b;
import std.regex;
//notice no import of a
void foo(){
...
static re = ctRegex!(...); //
...
}
and using ctRegex as usual in b, but any miss of compiled cache would
lead to a link error.
In fact it might be the best of both worlds if there is a switch to try
full CTFE vs link-time external option.
You may keep convenience but losing guarantees hurts a lot. To be able
to verify static correctness of your program / group of programs type
system needs to be aware how generated code relates to original source.
Build system does it. We have this problem with all of external deps
anyway (i.e. who verifies the right version of libXYZ is linked not some
other?)
Also this approach does not scale. I can totally imagine you doing it
for two or three DSL in single program, probably even dozen. But
something like 100+?
Not everything is suitable, of course. Some stuff is good only inline
and on spot. But it does use the same sources, it may look a lot like
this in case of REST generators:
import everything;
void main(){
foreach(m; module){
//... generate client code from meta-data
}
}
Waiting for 100+ DSL compiled in a JIT interpreter that can't optimize a
thing (pretty much by definition or use separate flags for that?) is not
going to be fun too.
Huge mess to maintain. According to my experience
all builds systems are incredibly fragile beasts, trusting them
something that impacts program correctness and won't be detected at
compile time is just too dangerous.
Could be, but we have dub which should be simple and nice.
I had very positive experience with scons and half-generated sources.
I heard D builds times are important part of its adoption so...
Adoption - yes. Production usage - less so (though still important).
Difference between 1 second and 5 seconds is very important. Between 10
seconds and 1 minute - not so much.
JIT will be probably slower than stand-alone generators but not that
slower.
It might solve most of _current_ problems, but I foresee fundamental
issues of no global state in CTFE that in say 10 years from now
would look a lot like `#include` in C++.
I hope 10 years ago from now we will consider having global state in
RTFE stone age relict :P
Well, no amount of purity dismisses the point that a cache is a cache.
When I say global in D I mean thread/fiber local.
A major one is there is no way for compiler to not recompile generated
code as it has no knowledge of how it might have changed from the
previous run.
Why can't we merge basic build system functionality akin to rdmd into
compiler itself? It makes perfect sense to me as build process can
benefit a lot from being semantically aware.
I wouldn't cross my fingers, but yes ideally it would need to have
powers of a build system making it that much more complicated. Then it
can cache results including templates instantiations across module and
separate invocations of the tool. It's a distant dream though.
Currently available caching at the level of object files is very coarse
grained and
Re: dmd front end now switched to Boost license
Dmitry Olshansky, el 14 de June a las 18:18 me escribiste: 14-Jun-2014 04:46, Walter Bright пишет: On 6/13/2014 4:31 AM, Dmitry Olshansky wrote: It's probably nice to have less restrictive license, but what we aim to achieve with that? I do not want to come across as rude but from pragmatic standpoint it's not interesting. I'm not opposing it (after all I agreed to change it), I just don't see any valuable gains. 1. Boost is the least restrictive license This gains nothing in and by itself. 4 speaks of potential adv, which realistically is not something we desperately want. Maybe as a proactive move, that I could understand. 2. Minimize friction for adopting D Let's not deluge ourselves, it does nothing to do that unlike many other things. Changing license of G++ frontend to boost won't make people adopt C++ any faster. The only place of friction is backend, and opening FE for commerce doesn't help it. 3. Harmonization with usage of Boost in the runtime library In other words simplify licensing, but again compiler and runtime library do not have to have anything in common. There is no issue to begin with. 4. Allow commercial use of DMDFE (so what if someone does? It'll drive even more adoption of D!) The only strictly valid point. Making commercial compilers and tools on D front-end is the only solid result this move enables. Except is completely invalid! No free license restrict commercial use. What using boost enable is only proprietary use, i.e. changing the DMD FE and keeping the changes private, even if you distribute the binary with the compiled DMDFE. As I said before, there are licenses that allow anyone linking your code to non-free code, but you still have to provide the source code of the modified DMDFE if you distribute it. An example is LGPL. 5. Boost is well known and accepted All of licenses are well known. Again by itself it's not interesting, it won't make dmd any more easy to get into FOSS distros. So, really, I all those 5 points are invalid. All the license change allows is people using the work of others without contributing back, without any real necessity like with the standard library that contains templates or code that gets copypasted into the users code. OK, as a side effect of this, this might encourage companies not to use D but to develop tools based on DMDFE, but companies that are too lazy or to BAD not to contribute the changes back, which I'm not sure is such a good idea. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- PITUFO ENRIQUE ATEMORIZA CATAMARCA, AMPLIAREMOS -- Crónica TV
Re: dmd front end now switched to Boost license
On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote: OK, as a side effect of this, this might encourage companies not to use D but to develop tools based on DMDFE, but companies that are too lazy or to BAD not to contribute the changes back, which I'm not sure is such a good idea. I believe it is good thing. Standard tool chain should be as permissive as possible, with no expectations from the potential users whatsoever. If someone goes with proprietary closed solution and succeeds - it is their choice and risk to do so.
Re: dmd front end now switched to Boost license
On 6/14/2014 3:58 AM, Joakim wrote: On Saturday, 14 June 2014 at 06:07:08 UTC, Nick Sabalausky wrote: I doubt it. First, it's the backend that's not technically OSI, frontend was (apparently) GPL. Second, I can't imagine any Linux distro rejecting GPL - they'd have to boot the kernel and core utils, too. Actually, the frontend was dual-licensed under the Artistic license and the GPL and dmd binaries were provided under the former, as the GPL doesn't allow linking against a non-GPL backend. The GPL alternative was likely for gdc to link the frontend against the GPL'd gcc backend. Well, GPL and Artistic are both OSI anyway.
Re: dmd front end now switched to Boost license
On 6/14/2014 10:18 AM, Dmitry Olshansky wrote: 14-Jun-2014 04:46, Walter Bright пишет: 3. Harmonization with usage of Boost in the runtime library In other words simplify licensing, but again compiler and runtime library do not have to have anything in common. There is no issue to begin with. Uhh, *no*. Scenario A: -- Them: What license does D use? Us: Well, it depends if you're talking about the compiler or Phobos, the standard library. Phobos is licensed under Boost, whereas the compiler is dual-licensed under both Artistic and one of the many GPLs. (Although the compiler's backend is a source-publicly-available proprietary due to insurmountable historical IP reasons. But GDC/LDC are fully OSS.) Them: Uhh...what? And WHY? And WTF? Us: You see, blah blah blah inclusion into user code blah blah Phobos templates blah blah blah GPL alternative blah blah GDC blah blah... Them: Jeesus, nevermind... -- Scenario B: -- Them: What license does D use? Us: Boost. (Although the compiler's backend is a source-publicly-available proprietary due to insurmountable historical IP reasons. But GDC/LDC are fully OSS.) Them: Huh. Weird, but whatever. -- I'll take B, thanks. ;)
Re: dmd front end now switched to Boost license
On Saturday, 14 June 2014 at 17:17:34 UTC, Dicebot wrote: On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote: OK, as a side effect of this, this might encourage companies not to use D but to develop tools based on DMDFE, but companies that are too lazy or to BAD not to contribute the changes back, which I'm not sure is such a good idea. I believe it is good thing. Standard tool chain should be as permissive as possible, with no expectations from the potential users whatsoever. If someone goes with proprietary closed solution and succeeds - it is their choice and risk to do so. And if they do so, it's beneficial to D overall.
Re: dmd front end now switched to Boost license
On 6/14/2014 11:03 AM, Nick Sabalausky wrote: I'll take B, thanks. ;) Right on, Nick. And there's another advantage I neglected to mention - it allows DMDFE code to be moved into Phobos without issues.
Re: dmd front end now switched to Boost license
On Saturday, 14 June 2014 at 18:43:59 UTC, Walter Bright wrote: And there's another advantage I neglected to mention - it allows DMDFE code to be moved into Phobos without issues. I don't think Nick's argument is particularly compelling, but the DDMD - Phobos connection definitely makes the change very worthwhile in my opinion. David
Re: dmd front end now switched to Boost license
On 14 June 2014 19:03, Nick Sabalausky via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 6/14/2014 10:18 AM, Dmitry Olshansky wrote: 14-Jun-2014 04:46, Walter Bright пишет: 3. Harmonization with usage of Boost in the runtime library In other words simplify licensing, but again compiler and runtime library do not have to have anything in common. There is no issue to begin with. Uhh, *no*. Scenario A: -- Them: What license does D use? Us: Well, it depends if you're talking about the compiler or Phobos, the standard library. Phobos is licensed under Boost, whereas the compiler is dual-licensed under both Artistic and one of the many GPLs. (Although the compiler's backend is a source-publicly-available proprietary due to insurmountable historical IP reasons. But GDC/LDC are fully OSS.) Them: Uhh...what? And WHY? And WTF? Us: You see, blah blah blah inclusion into user code blah blah Phobos templates blah blah blah GPL alternative blah blah GDC blah blah... Them: Jeesus, nevermind... -- Scenario B: -- Them: What license does D use? Us: Boost. (Although the compiler's backend is a source-publicly-available proprietary due to insurmountable historical IP reasons. But GDC/LDC are fully OSS.) Them: Huh. Weird, but whatever. -- I'll take B, thanks. ;) You should really practise explaining things in a more succinct manner. ;-) When I look at a project, my first question is never What license does it use? - that should be of little importance to anyone using D. If you wish to contribute, your question should be smarter, reword the question to Does this project allow me freely study, modify and re-distribute it's code, and does it guarantee that any contributions I make are released under the same freedom as I get when I received the software?
Re: dmd front end now switched to Boost license
14-Jun-2014 22:03, Nick Sabalausky пишет: On 6/14/2014 10:18 AM, Dmitry Olshansky wrote: 14-Jun-2014 04:46, Walter Bright пишет: 3. Harmonization with usage of Boost in the runtime library In other words simplify licensing, but again compiler and runtime library do not have to have anything in common. There is no issue to begin with. Uhh, *no*. Scenario A: -- Them: What license does D use? Me: WAT? Language is not a product in itself. What license C++ use then? In short, everything they care about was and is Boost. -- Dmitry Olshansky
Re: dmd front end now switched to Boost license
On 6/14/2014 9:02 AM, Leandro Lucarella wrote: Not really, the standard library is included into user code (because of the templates), and that's the reason why it needs to be under a very permissive license. The compiler, on the other hand, doesn't, and one could agree is good to force people wanting to build products using the compiler FE to contribute changes back. I guess the main purpose of this is encourage proprietary tools based on the FE, but if that's the case, there are better licenses for this, like the LGPL, which let proprietary tools to link code against the DMD FE without having to release their code under a free license. Yes, it allows people to use DMDFE for whatever they want, including closed source proprietary tools. I understand very well how upsetting someone taking your code, creating a CSPT and making money off of it without acknowledging you or contributing back to it. This happened to me with my game Empire. It's a long and convoluted story, and I won't bore you with it, just suffice to say I am not a stranger to how you feel about it. But D is different from a game in that it has network effects - the more adoption it gets, the more momentum for adoption it accrues. By giving up a slice of the pie the pie more than grows enough to compensate. In other words, the D community still gains even if there are a few CSPTs made from the front end.
Re: dmd front end now switched to Boost license
On 6/14/2014 2:47 PM, David Nadlinger wrote: On Saturday, 14 June 2014 at 18:43:59 UTC, Walter Bright wrote: And there's another advantage I neglected to mention - it allows DMDFE code to be moved into Phobos without issues. I don't think Nick's argument is particularly compelling, Granted, it isn't a very big technical/legal argument, but I don't think those are the only important criteria. The thing is, D's licensing overall (DMDFE/DMDBE/LDC/GDC/Phobos) is kinda complicated. So any simplification, as long as it doesn't restrict anyone, is a net improvement, even if it isn't earth-shattering. but the DDMD - Phobos connection definitely makes the change very worthwhile in my opinion. Yea, I agree too, I hadn't thought of that one either.
Re: dmd front end now switched to Boost license
On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote: No free license restrict commercial use. What using boost enable is only proprietary use, i.e. changing the DMD FE and keeping the changes private, even if you distribute the binary with the compiled DMDFE. As I said before, there are licenses that allow anyone linking your code to non-free code, but you still have to provide the source code of the modified DMDFE if you distribute it. An example is LGPL. The frontend was dual-licensed under the Artistic license, which also allows such proprietary use, so nothing has really changed. Rather than having two licenses, the Artistic license to allow linking against the proprietary dmd backend and the GPL to allow linking against the gcc backend, the dmd frontend now has a single Boost license that allows both, since the Boost license is considered GPL-compatible. From the standpoint of what the frontend's license allows, not much has changed, but the simplicity and clarity of the Boost license puts the frontend on firmer footing. I realize you prefer the LGPL, to force others to contribute back to the frontend if they modify and distribute it, but the Boost license is much simpler and as Walter points out, proprietary use can help D's adoption.
Re: DlangUI
Very nice, thanks. I'm looking forward to trying it out when I can find the time. I'm not a big fan of bindings/wrappers. Jim
Re: Dfix
As it happens I am writing a kind of DFIX on top of DScanner right at the moment. There are a few details to sort out. But I should have some small demo pretty soon. Regrards, Stefan
Re: dmd front end now switched to Boost license
On 6/14/2014 2:52 PM, Dmitry Olshansky wrote: 14-Jun-2014 22:03, Nick Sabalausky пишет: Scenario A: -- Them: What license does D use? Me: WAT? Language is not a product in itself. While that's technically true, people often think of them as complete products anyway. Esp with so many of the newer languages now having a main/official compiler/lib. What license C++ use then? In short, everything they care about was and is Boost.
Re: DMD 2.066 Alpha
On Fri, 13 Jun 2014 12:00:39 -0700 Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 6/13/14, 10:15 AM, Nick Sabalausky wrote: On 6/13/2014 12:49 PM, Andrei Alexandrescu wrote: Being able to negate the final: label is nice to have but not a must. Adding a keyword for that doesn't scale - it would mean we'd need to add one keyword to undo each label. No it doesn't mean that. virtual is very well established industry-wide as the anti-final. Just because we accept that does not mean we can't still do @~pure, @nothrow(false) or whatever for the ones which don't already have well-established names. I don't see it necessary to add the virtual as a keyword to D. -- If we were going to go with final by default, then adding virtual would make a lot of sense IMHO - especially given that's what people expect from other languages and the fact that virtual would the likely be used far more often than final. Without that however, marking a function as virtual becomes a lot less critical, and it becomes a question of whether the familiarity of using virtual instead of !final or final(false) (or whatever we come up with) is worth adding another keyword and having it in addition to !final or final(false) or whatever (since presumably, we'd still need that for generic code even with virtual). And actually, having virtual would then open the door for !virtual or virtual(false) or whatever in addition to !final or final(false), etc. So, while having virtual would be nice, it's probably complicating things too much from the user's perspective when combined with the ability to explicitly negate attributes. - Jonathan M Davis
Re: dmd front end now switched to Boost license
Kapps, el 14 de June a las 18:19 me escribiste: On Saturday, 14 June 2014 at 17:17:34 UTC, Dicebot wrote: On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote: OK, as a side effect of this, this might encourage companies not to use D but to develop tools based on DMDFE, but companies that are too lazy or to BAD not to contribute the changes back, which I'm not sure is such a good idea. I believe it is good thing. Standard tool chain should be as permissive as possible, with no expectations from the potential users whatsoever. If someone goes with proprietary closed solution and succeeds - it is their choice and risk to do so. And if they do so, it's beneficial to D overall. Not if they don't contribute back the changes (at least compared to using a license that allows them to build proprietary tools by linking to DMDFE but forcing them to contribute back the changes to DMDFE itself). I find hard to believe companies willing to do a full closed source proprietary tool are willing to use DMDFE with Boost license but not with LGPL. In any case, I clarify once more that probably in practice this makes a very tiny difference because usually you have to be too stupid to maintain a fork instead of contributing changes back and let upstream take care of all the updates, so I think that will hardly happens, this is more a ethical issue than a practical issue. I just wanted to point out that there might be more ethical licenses to achieve the same effect (allowing companies to build proprietary tools on top on DMDFE). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- ¿Cómo estais? ¿Cómo os senteis hoy 29 del membre de 1961 día en que conmemoreramos la nonésima setima nebulización del martir Peperino Pómoro junto al Rolo Puente en la ciudad de Jadad? -- Peperino Pómoro
Re: dmd front end now switched to Boost license
David Nadlinger, el 14 de June a las 18:47 me escribiste: On Saturday, 14 June 2014 at 18:43:59 UTC, Walter Bright wrote: And there's another advantage I neglected to mention - it allows DMDFE code to be moved into Phobos without issues. I don't think Nick's argument is particularly compelling, but the DDMD - Phobos connection definitely makes the change very worthwhile in my opinion. Agreed, so far this looks like the most important gain from the change, and I can see some sense on using the boost license instead of something like lgpl. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Ambition makes you look pretty ugly
Re: dmd front end now switched to Boost license
Joakim, el 14 de June a las 19:31 me escribiste: On Saturday, 14 June 2014 at 17:07:58 UTC, Leandro Lucarella wrote: No free license restrict commercial use. What using boost enable is only proprietary use, i.e. changing the DMD FE and keeping the changes private, even if you distribute the binary with the compiled DMDFE. As I said before, there are licenses that allow anyone linking your code to non-free code, but you still have to provide the source code of the modified DMDFE if you distribute it. An example is LGPL. The frontend was dual-licensed under the Artistic license, which also allows such proprietary use, so nothing has really changed. Mmm, even when is true that the Artistic license is a bit more permissive than the GPL in some aspects, I think is hardly suitable for doing serious proprietary software (that you intent to sell). From the artistic license that was distributed by DMD: You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. Is a bit hairy, I don't think any companies would want to do proprietary tools using the artistic license :) https://github.com/D-Programming-Language/dmd/blob/083271a415716cf3e35321f91826397d91c0a731/src/artistic.txt I realize you prefer the LGPL, to force others to contribute back to the frontend if they modify and distribute it, but the Boost license is much simpler and as Walter points out, proprietary use can help D's adoption. Again, I think from the practical point of view is the same. If you use boost license and tons of proprietary tools come out CHANGING the DMDFE and not contributing back, then the D community might get a boost because the have better tools but they are missing the contributions, so is hard to tell if the balance would be positive or negative. If they don't change the DMDFE (or contribute back the changes), then using boost or LGPL are the same, because it doesn't matter. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- El techo de mi cuarto lleno de galaxias
Re: DMD 2.066 Alpha
On 6/14/2014 5:49 PM, Jonathan M Davis via Digitalmars-d-announce wrote: and it becomes a question of whether the familiarity of using virtual instead of !final or final(false) (or whatever we come up with) is worth adding another keyword FWIW, I don't think virtual is all that valuable as a user-defined keyword anyway. But, emphasis on FWIW.
