Free the DMD backend

Hi,

this is a short ping about one of D's weaknesses - the 
restrictive license for the backend. IIRC [1, 2, 3] the status is 
that because some parts have been written by Walter while he was 
employed by Symantec, it can't get an open-source license.
When I read the backend license [4], I read the following:

> The Software is copyrighted and comes with a single user 
> license,
and may not be redistributed. If you wish to obtain a 
redistribution license,
please contact Digital Mars.

This actually means that all the 366 forks on Github would 
require approval by Digital Mars.
So luckily neither Symantec nor Digital Mars seem to bother much 
about the license, so why can't it be changed in an free & open 
source license that allows
free redistribution and modification?

This would also make it possible to distribute dmd out-of-the-box 
on the two biggest Linux distributions Debian and Ubuntu [5, 6].

[1] http://tomash.wrug.eu/blog/2009/03/06/free-the-dmd/
[2] 
http://forum.dlang.org/post/ikwvgrccoyhvvizcjvxd <at> forum.dlang.org
[3] 
https://semitwist.com/articles/article/view/dispelling-common-d-myths

(Continue reading)

Re: Transient ranges

On Saturday, 28 May 2016 at 21:32:15 UTC, Brad Roberts wrote:
> On 5/28/2016 10:27 AM, Joseph Rushton Wakeling via 
> Digitalmars-d wrote:
>> On Saturday, 28 May 2016 at 01:48:08 UTC, Jonathan M Davis 
>> wrote:
>>> On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
>>>> So what about the convention to explicitely declare a 
>>>> `.transient`
>>>> enum member on a range, if the front element value can 
>>>> change?
>>>
>>> Honestly, I don't think that supporting transient ranges is 
>>> worth it.
>>
>> I have personally wondered if there was a case for a 
>> TransientRange
>> concept where the only primitives defined are `empty` and 
>> `front`.
>>
>> `popFront()` is not defined because the whole point is that 
>> every single
>> call to `front` will produce a different value.
>
> Um. that's wrong, just look at byLine as evidence.  It is 
> popFront that changes the value to the 'next' one in the 
> iteration.  Front called twice in a row does NOT change the 
> value, and shouldn't.  I think you're misunderstanding 
> something.

I'm not talking about how byLine currently behaves.  I'm talking 
(Continue reading)

Seb via Digitalmars-d | 28 May 19:50 2016

Copyright for Phobos to D Foundation

One thing that confused me a lot in the beginning, is that every 
Phobos module has it's own copyright - I am not a lawyer, but it 
sounded for me pretty weird that in theory I could get sued by a 
lot of Oracle-like patent trolls.
I imagine the same effect also for companies when they read a 
different copyright on every module in Phobos.

Now that D foundation finally got its own page [1], it's probably 
time to start this dicussion.
Is it safe to assume that the entire Phobos source code (except 
for the external C modules), belongs to the D foundation?

Ping  <at> WalterBright,  <at> andralex & people with legal experience.

[1] https://github.com/dlang/dlang.org/pull/1311

Re: Transient ranges

On Saturday, 28 May 2016 at 01:48:08 UTC, Jonathan M Davis wrote:
> On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
>> So what about the convention to explicitely declare a 
>> `.transient` enum member on a range, if the front element 
>> value can change?
>
> Honestly, I don't think that supporting transient ranges is 
> worth it.

I have personally wondered if there was a case for a 
TransientRange concept where the only primitives defined are 
`empty` and `front`.

`popFront()` is not defined because the whole point is that every 
single call to `front` will produce a different value.

We need to talk about error messages of functions that are passed into other functions at compile time

I really like D's syntax for lambdas and I usually write code 
like this

   auto v = validationLayers[].all!((layerName){
     return layerProps[].count!((layer){
       return strcmp(cast(const(char*))layer.layerName, layerName) 
== 0;
     }) > 0;
   });

But this gives you basically 0 helpful error messages:

"Error: template 
breeze.graphics.context.createContext.all!((layerName)
{
return layerProps[].count!((layer)
{
return strcmp(cast(const(char*))layer.layerName, layerName) == 0;
}
) > 0;
}
).all cannot deduce function from argument types 
!()(const(char*)[]), candidates are:
/usr/include/dmd/phobos/std/algorithm/searching.d(113,10):        
breeze.graphics.context.createContext.all!((layerName)
{
return layerProps[].count!((layer)
{
return strcmp(cast(const(char*))layer.layerName, layerName) == 0;
}
(Continue reading)

Re: Our Sister

On Saturday, 28 May 2016 at 04:15:45 UTC, Manu wrote:
> This is only true for the owner. If we had 'scope', or 
> something like
> it (ie, borrowing in rust lingo), then the fat slice wouldn't 
> need to
> be passed around

Right, I agree - if we keep the slice just the way it is now, it 
all still works if you borrow correctly!

(BTW, I don't think we even need this to be strictly  <at> safe, 
though it would be nice if it was tested, we could say  <at> system 
getSlice and potentially change it to  <at> safe later.)

Re: Our Sister

On Saturday, 28 May 2016 at 04:28:16 UTC, Manu wrote:
> On 27 May 2016 at 23:32, Andrei Alexandrescu via Digitalmars-d 
> <digitalmars-d <at> puremagic.com> wrote:
>> On 5/27/16 7:07 AM, Marc Schütz wrote:
>>> It should _safely_ convert to `const(char)[]`.
>>
>>
>> That is not possible, sorry. -- Andrei
>
> It should safely convert to 'scope const(char)[]', then we only 
> need a fat-slice or like at the very top of the callstack...

I didn't want to mention the s-word ;-)

cym13 via Digitalmars-d | 28 May 12:03 2016

Re: Transient ranges

On Saturday, 28 May 2016 at 01:48:08 UTC, Jonathan M Davis wrote:
> On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
>> So what about the convention to explicitely declare a 
>> `.transient` enum member on a range, if the front element 
>> value can change?
>
> Honestly, I don't think that supporting transient ranges is 
> worth it. Every single range-based function would have to 
> either test that the "transient" enum wasn't there or take 
> transient ranges into account, and realistically, that isn't 
> going to happen. For better or worse, we do have byLine in 
> std.stdio, which has a transient front, but aside from the 
> performance benefits, it's been a disaster. It's way too 
> error-prone. We now have byLineCopy to combat that, but of 
> course, byLine is the more obvious function and thus more 
> likely to be used (plus it's been around longer), so a _lot_ of 
> code is going to end up using it, and a good chunk of that code 
> really should be using byLineCopy.
>
> I'm of the opinion that if you want a transient front, you 
> should just use opApply and skip ranges entirely. Allowing for 
> front to be transient - whether you can check for it or not - 
> simply is not worth the extra complications. I'd love it if we 
> deprecated byLine's range functions, and made it use opApply 
> instead and just declare transient ranges to be completely 
> unsupported. If you want to write your code to have a transient 
> front, you can obviously take that risk, but you're on your own.
>
> - Jonathan M Davis

(Continue reading)

Re: Our Sister

On Saturday, 28 May 2016 at 04:31:22 UTC, Manu wrote:
> On 27 May 2016 at 02:11, Andrei Alexandrescu via Digitalmars-d 
> <digitalmars-d <at> puremagic.com> wrote:
>> I've been working on RCStr (endearingly pronounced "Our 
>> Sister"),
>
> Ah, I totally skipped over this thread...
>
> Wow... this really doesn't work in any accent I'm close to, but 
> I can
> hear it if I imagine you saying it ;)
> If I said RCStr, it sounds like 'are'-'see'-strrr, but 'our 
> sister'
> would be 'hour'-sistə... isn't it strange that word recognition 
> seems
> to work pretty much reliably down a sliding scale until an 
> arbitrary
> point where it just drops off. There's not a lot of fuzzy area 
> in the
> middle.

The joke is revealed when you consider the fact that there are no 
females in this community, let alone sisters.  A kind of joke 
that's funny only to certain types of men.

Now let's get back to fixing things before the world finds out 
that D is full of holes.

Seb via Digitalmars-d | 28 May 01:42 2016

Transient ranges

A couple of weeks ago on the next/shift convenience wrapper 
discussion [1], there was a nice discussion about transient 
ranges. It didn't come to a conclusion, so let's revie it. I just 
cite the best three quotes from the thread as a summary:

jmdavis:

> The reality of the matter is that ranges with a transient front 
> tend to break if you do much more than use foreach on them. 
> They don't even work with std.array.array

schveiguy:

> There is an implicit expectation that if you assign the front 
> of a range to something, it's going to last forever, because 
> many ranges do actually behave that way. But the range contract 
> does not guarantee that, it just happens to work.

quickfur:

> isTransient can only be implemented if the range implementor 
> defines its value. There is no way to know whether a range is 
> transient or not just by looking at its type and the signatures 
> of front, popFront, etc.. Having said that, though, since 
> transient ranges are generally the exception rather than the 
> norm, we could adopt a convention that transient ranges declare 
> themselves thus by defining a .transient enum member or 
> something like that, and have isTransient return false if a 
> range doesn't have such a member.

(Continue reading)

Re: The Case Against Autodecode

On 05/27/2016 03:43 PM, H. S. Teoh via Digitalmars-d wrote:
> That's what we've been trying to say all along!

If that's the case things are pretty dire, autodecoding or not. -- Andrei


Gmane