date:20141113


On Thursday, 13 November 2014 at 01:45:31 UTC, ZombineDev wrote:

Probably more important:

Microsoft starts to open source .NET and take it cross-platform 
to Mac, Linux:


http://venturebeat.com/2014/11/12/microsoft-starts-to-open-source-net-and-take-it-cross-platform-to-mac-linux/

https://github.com/Microsoft/dotnet

License

.NET open source projects typically use either the MIT or 
Apache 2 licenses for code. Some projects license documentation 
and other forms of content under Creative Commons Attribution 
4.0. See specific projects to understand the license used.


Yeah, I thought that was cool. The JIT, GC  and core library.

https://github.com/dotnet/corefx

So, how to write a source-to-source compiler from CS to D…? ;-)

Re: Why is `scope` planned for deprecation?

Are you guys saying you don't feel this proposal is practical?
http://wiki.dlang.org/User:Schuetzm/scope

I think it's a very interesting approach, and comes from a practical
point of view. It solves the long-standings issues, like scope return
values, in a very creative way.

On 13 November 2014 08:33, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On 11/12/14 2:10 PM, deadalnix wrote:

 On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven
 wrote:

 I think Rust's lifetimes would be a huge change if ported to D. In
 Rust user types often need annotations as well as function parameters.
 People tend to want Rust's guarantees without the limitations. I think
 D does need some kind of scope attribute verification, but we need to
 throw out some of the guarantees Rust makes to get an appropriate fit
 for existing D code.


 Rust is not the first language going that road. The problem is
 that you get great complexity if you don't want to be too
 limiting in what you can do. This complexity ultimately ends up
 costing more than what you gain.

 I think the sane road to go into is supporting
 ownership/burrowing for common cases, and fallback on the GC, or
 unsafe construct for the rest.

 One have to admit there is no silver bullet, and shoehorning
 everything in the same solution is not gonna work.


 I agree. This is one of those cases in which a good engineering solution may
 be a lot better than the perfect solution (and linear types are not even
 perfect...).

 Andrei

Re: Microsoft now giving away VS 2013

On 13 November 2014 10:57, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/

 This is good news for D! It lowers the bar for writing 64 bit D code on
 Windows, and it also enables us to abandon support for versions of VS prior
 to 2013.

Many, many corporate VS users get stuck on legacy versions of VS for a
very long time. We still use VS2010 at work for instance, with no plan
to upgrade.
It would be a shame to lose legacy VS support, but I think the focus
should certainly emphasise these future releases.

A really nice start would be supporting the modern VS debugging stuff,
for instance, the latest VS can track variables in registers for
debugging release code... that would be a massive win! :)
(Note: We should also be able to inspect class members, and step
through code with scope's properly... so I won't hold my breath _)

Re: Microsoft now giving away VS 2013

2014-11-13 Thread Paulo Pinto via Digitalmars-d

On Thursday, 13 November 2014 at 00:58:41 UTC, Walter Bright 
wrote:

http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/

This is good news for D! It lowers the bar for writing 64 bit D 
code on Windows, and it also enables us to abandon support for 
versions of VS prior to 2013.


Actually I think it makes the life harder to earn Windows 
developers hearts for D, specially with .NET Native around the 
corner (it will come in Windows 10).


Free Visual Studio + C#/F# + SIMD + .NET Native is a very 
enticing proposal.


I would have a very hard time to convince any of our customers to 
use D instead.


--
Paulo

Re: Why is `scope` planned for deprecation?

2014-11-13 Thread bearophile via Digitalmars-d


Andrei Alexandrescu:

I agree. This is one of those cases in which a good engineering 
solution may be a lot better than the perfect solution (and 
linear types are not even perfect...).


I am sure you are aware that the solution you are talking about 
is rather more complex (for both final programmers and language 
implementators) than the Rust solution.


Bye,
bearophile

Re: C++ overloaded operators and D

On Wednesday, 12 November 2014 at 21:17:42 UTC, IgorStepanov 
wrote:
On Wednesday, 12 November 2014 at 20:49:42 UTC, Marc Schütz 
wrote:
On Wednesday, 12 November 2014 at 19:32:32 UTC, IgorStepanov 
wrote:
On Wednesday, 12 November 2014 at 14:41:17 UTC, Marc Schütz 
wrote:
On Wednesday, 12 November 2014 at 11:43:36 UTC, IgorStepanov 
wrote:
C++ and D provides different behaviour for operator 
overloading.
D has a opIndex + opIndexAssign overloads, and if we want 
to map opIndex to operator[], we must to do something with 
opIndexAssign.


operator[] can be mapped to opIndex just fine, right? Only 
opIndexAssign wouldn't be accessible from C++ via an 
operator, but that's because the feature doesn't exist. We 
can still call it via its name opIndexAssign.


operator and operator can't be mapped to D. Same for 
operator.


That's true. Maybe we can just live with pragma(mangle) for 
them, but use D's op... for all others?


Binary arithmetic operators can't be mapped to D, if them 
implemented as static functions:


Foo operator+(int a, Foo f); //unable to map it to D, 
because static module-level Foo opAdd(int, Foo) will not 
provide the same behaviour as operator+ in D.
Thus: C++ and D overloaded operators should live in 
different worlds.


Can't we map both static and member operators to opBinary 
resp. opBinaryRight members in this case? How likely is it 
that both are defined on the C++ side, and if they are, how 
likely is it that they will behave differently?


opBinary(Right) is a template-functions. You can't add 
previous declaration for it to struct:


//C++
struct Foo
{
  Foo operator+(const Foo);
};

Foo operator+(int, const Foo);

//D
extern(C++)
struct struct Foo
{
  Foo opBinary!+(const ref Foo); //???


I see...


}

Foo opBinary!+(int, const ref Foo); //???


But this would of course be opBinaryRight, and inside struct 
Foo.


What if
Foo operator+(const Bar, const Foo);?
Is it Foo.opBinaryRight, or Bar.opBinary, or both?


For a C++ class interfaced from D: opBinary() in whichever of the 
two classes it is defined.


For a D class interfaced from C++: choose one, preferably 
opBinary(), as it's the natural one.

Re: Why is `scope` planned for deprecation?

On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via 
Digitalmars-d wrote:

Are you guys saying you don't feel this proposal is practical?
http://wiki.dlang.org/User:Schuetzm/scope

I think it's a very interesting approach, and comes from a 
practical
point of view. It solves the long-standings issues, like scope 
return

values, in a very creative way.



You need to define ownership before defining borrowing.

Re: Why is `scope` planned for deprecation?

On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via 
Digitalmars-d wrote:

Are you guys saying you don't feel this proposal is practical?
http://wiki.dlang.org/User:Schuetzm/scope

I think it's a very interesting approach, and comes from a 
practical
point of view. It solves the long-standings issues, like scope 
return

values, in a very creative way.


It is better solved using static analysis and it is part of a 
bigger problem complex where ref counting should be considered. 
Otherwise you end up writing N versions of the same code. You 
want the same interface for GC, shared_ptr, unique_ptr, 
stack_allocated_data etc. Let the compiler do the checking.


What does shared tell the compiler? It tells it retain no 
references after completion of this function. Like with pure, 
it should be opposite. You should tell the compiler I transfer 
ownership of this parameter. Then have a generic concept owned 
for parameters that is resolved using templates. Types that can 
be owned has to provide release() and move(). That would work for 
GC, shared_ptr, unique_ptr, but not for stack allocated data:


GC ptr: release() and move() are dummies.

shared_ptr: release() decrements, move() just transfers

unique_ptr: release() destroys, move() transfers

D has to stop adding crutches. Generalize!

Re: On heap segregation, GC optimization and @nogc relaxing


On Wednesday, 12 November 2014 at 21:15:05 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 12:49:41 UTC, Marc Schütz 
wrote:
All this is unfortunately only true if there are no references 
between heaps, i.e. if the heaps are indeed islands. 
Otherwise, there need to be at least write barriers.




Yes, that is exactly why I'm listing the case where these can 
be created in @safe code and propose a solution to plug the 
hole (and which brings other benefits along the road).


Hmm... I can't find that in what you wrote. To clarify: I'm 
talking about the fact that, for example, a thread-local heap can 
contain references into the immutable and shared heaps. 
Therefore, the immutable heap can _not_ be collected without 
disturbing any threads, because any TL heaps (and stacks!) can 
potentially have references to it. They either need to be 
stopped, or write barriers need to be utilized when references to 
immutable data are changed.

Re: Microsoft now giving away VS 2013

2014-11-13 Thread Kagamin via Digitalmars-d


On Thursday, 13 November 2014 at 01:45:31 UTC, ZombineDev wrote:

http://venturebeat.com/2014/11/12/microsoft-starts-to-open-source-net-and-take-it-cross-platform-to-mac-linux/

.NET open source projects typically use either the MIT or 
Apache 2 licenses for code. Some projects license documentation 
and other forms of content under Creative Commons Attribution 
4.0. See specific projects to understand the license used.


It can sound more optimistic, than it is. Framework is big, and 
what will be opensourced is unknown. As of now, it's only 
immutable collections and XmlDocument. ASP.NET vNext stuff looks 
like a limited rewrite than a published source.

Re: Why is `scope` planned for deprecation?

On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim 
Grøstad wrote:
On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via 
Digitalmars-d wrote:

Are you guys saying you don't feel this proposal is practical?
http://wiki.dlang.org/User:Schuetzm/scope

I think it's a very interesting approach, and comes from a 
practical
point of view. It solves the long-standings issues, like scope 
return

values, in a very creative way.


It is better solved using static analysis


You mean without additional hints by the programmer? That's not 
going to happen, realistically, for many reasons, separate 
compilation being one of them.


and it is part of a bigger problem complex where ref counting 
should be considered. Otherwise you end up writing N versions 
of the same code. You want the same interface for GC, 
shared_ptr, unique_ptr, stack_allocated_data etc. Let the 
compiler do the checking.


Huh? That's exactly what _borrowing_ does. Ref-counting OTOH adds 
yet another reference type and thereby makes the situation worse.




What does shared tell the compiler?


I guess you mean scope?

It tells it retain no references after completion of this 
function. Like with pure, it should be opposite. You should 
tell the compiler I transfer ownership of this parameter. 
Then have a generic concept owned for parameters that is 
resolved using templates.


That's what deadalnix's proposal does. Though I don't quite see 
what templates have to do with it.


Types that can be owned has to provide release() and move(). 
That would work for GC, shared_ptr, unique_ptr, but not for 
stack allocated data:


GC ptr: release() and move() are dummies.

shared_ptr: release() decrements, move() just transfers

unique_ptr: release() destroys, move() transfers



For a new language built from scratch, this might make sense. D 
is already existing, and needs to work with what it has.



D has to stop adding crutches. Generalize!


That's what I'm trying to do with my proposal :-)

Re: Why is `scope` planned for deprecation?

On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim 
Grøstad wrote:

GC ptr: release() and move() are dummies.


Well, move() should obviously not be a dummy, but just a 
regular assignment that requires the object to be GC allocated…


What I am saying is that D needs type-classes for pointers so 
that you can write generic functions can be ignorant to specific 
allocation schemes and specify their minimum requirements. It 
basically means that in @safe code all raw pointers are 
borrowed and all owned pointers requires specification tha is 
either concrete (gc,shared,unique) or a templated generalization 
(single ownership, multiple ownership etc).


It seems a perfect for D to extend templates with more power and 
make good use of it now that C++ adds concepts.

Re: Why is `scope` planned for deprecation?

On 13 November 2014 19:56, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via Digitalmars-d wrote:

 Are you guys saying you don't feel this proposal is practical?
 http://wiki.dlang.org/User:Schuetzm/scope

 I think it's a very interesting approach, and comes from a practical
 point of view. It solves the long-standings issues, like scope return
 values, in a very creative way.


 You need to define ownership before defining borrowing.

I don't think this proposal has issues with that.
The thing at the root of the call tree is the 'owner'. Nothing can
escape a scope call-tree, so the owner or allocation policy doesn't
matter, and that's the whole point.

Re: either me or GC sux badly (GC don't reuse free memory)

2014-11-13 Thread Kagamin via Digitalmars-d

On Wednesday, 12 November 2014 at 16:47:47 UTC, ketmar via 
Digitalmars-d wrote:
but this clearly not an issue with sample which does 
`GC.free()`, and
it stops at 1.7GB, while C sample does the same and stops at 
2.9GB.


GC probably allocates some small blocks for pools and other data. 
If it gets in a middle of address space, that can cause 
fragmentation too. Try to add small allocations to the C sample 
too.

Re: Byron Scott is not a fan

2014-11-13 Thread thedeemon via Digitalmars-d


On Thursday, 13 November 2014 at 06:08:46 UTC, Joakim wrote:

Byron Scott on D: 'It was just terrible' :)

http://espn.go.com/los-angeles/nba/story/_/id/11868151/los-angeles-lakers-coach-byron-scott-rips-team-lack-defense


It's on Go.com, obviously biased. ;)

Re: Why is `scope` planned for deprecation?


On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz wrote:
On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim 
Grøstad wrote:

It is better solved using static analysis


You mean without additional hints by the programmer? That's not 
going to happen, realistically, for many reasons, separate 
compilation being one of them.


I think it can happen. D needs a new intermediate layer where you 
can do global flow analysis.


compile src - ast - partial evaluation - high level IR - disk

instantiate high level IR - intermediate IR - disk

global analysis over  intermediate IR

intermediate IR - LLVM - asm

Huh? That's exactly what _borrowing_ does. Ref-counting OTOH 
adds yet another reference type and thereby makes the situation 
worse.


I don't like explicit ref counting, but it is sometimes useful 
and I think Rust-style ownership is pretty close to unique_ptr 
which is ref-counting with a max count of 1… You can also view GC 
as being implicitly ref counted too (it is counted during 
collection).



What does shared tell the compiler?


I guess you mean scope?


:)

It tells it retain no references after completion of this 
function. Like with pure, it should be opposite. You should 
tell the compiler I transfer ownership of this parameter. 
Then have a generic concept owned for parameters that is 
resolved using templates.


That's what deadalnix's proposal does. Though I don't quite see 
what templates have to do with it.


My understanding of Deadalnix' proposal is that owned objects 
can only reference other owned objects. I think region 
allocators do better if you start constraining relations by 
ownership.


For a new language built from scratch, this might make sense. D 
is already existing, and needs to work with what it has.


D need to appropriate what C++ has and do it better. Basically it 
means integrating GC pointers with unique_ptr and shared_ptr.


If D is going to be stuck on what it has and fix it with addig 
crutches it will go nowhere, and C++ will start to look like a 
better option…

Re: On heap segregation, GC optimization and @nogc relaxing


On Thursday, 13 November 2014 at 10:10:34 UTC, Marc Schütz wrote:
potentially have references to it. They either need to be 
stopped, or write barriers need to be utilized when references 
to immutable data are changed.


I sometimes wonder if the very pragmatic and brutal option of 
just having GC on the main thread and prevent all escapes of 
objects from the main thread without explicit ownership transfer 
would solve D's GC performance related problems.


It would work for real time applications and it would work for 
people who use D in a scripty fashion (but not for vibe.d).

Re: Why is `scope` planned for deprecation?

On 13 November 2014 20:38, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz wrote:

 D need to appropriate what C++ has and do it better. Basically it means
 integrating GC pointers with unique_ptr and shared_ptr.

 If D is going to be stuck on what it has and fix it with addig crutches it
 will go nowhere, and C++ will start to look like a better option…

I don't follow how you associate that opinion with implementation of
scope. I think it's practical and important, and the point is the
opposite of what you say from my perspective.
scope is the best approach I've heard to address these differences in
allocation patterns without asserting any particular policy on the
user. Escape analysis is the only solution I know to safely allow
pointers to be passed around without having to worry about how they
were allocated.
By contrast, I have no idea what you're suggesting, or how it's not a
'crutch'... but if it's anything to do with C++, I'm dubious, and
kinda frightened.


Incidentally, I've recently started a new C++ job, first C++ I've
written in some years... (after ~18 years, 12 professionally,
full-time C/C++)
After having adapted to D and distancing from C++, trying to go back
is like some form of inhuman torture!
I really don't remember it being as bad as it is... the time away has
given me new perspective on how terrible C++ is, and I can say with
confidence, there is NOTHING C++ could do to make itself a 'better
option' at this point.
Judged on common ground, there is no competition. It's only 'the devil
you know' case that I think can possibly make an argument for C++.

Re: Why is `scope` planned for deprecation?

2014-11-13 Thread Daniel Murphy via Digitalmars-d

Manu via Digitalmars-d  wrote in message 
news:mailman.1926.1415879071.9932.digitalmar...@puremagic.com...



Incidentally, I've recently started a new C++ job, first C++ I've
written in some years... (after ~18 years, 12 professionally,
full-time C/C++)
After having adapted to D and distancing from C++, trying to go back
is like some form of inhuman torture!
I really don't remember it being as bad as it is... the time away has
given me new perspective on how terrible C++ is, and I can say with
confidence, there is NOTHING C++ could do to make itself a 'better
option' at this point.
Judged on common ground, there is no competition. It's only 'the devil
you know' case that I think can possibly make an argument for C++.


I know, it's easy to forget how bad C++ is to work with.  The new versions 
have fixed some of the pain points, but only some.

Re: Why is `scope` planned for deprecation?

2014-11-13 Thread Paulo Pinto via Digitalmars-d

On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via 
Digitalmars-d wrote:

On 13 November 2014 20:38, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz 
wrote:


D need to appropriate what C++ has and do it better. Basically 
it means

integrating GC pointers with unique_ptr and shared_ptr.

If D is going to be stuck on what it has and fix it with 
addig crutches it
will go nowhere, and C++ will start to look like a better 
option…


I don't follow how you associate that opinion with 
implementation of
scope. I think it's practical and important, and the point is 
the

opposite of what you say from my perspective.
scope is the best approach I've heard to address these 
differences in
allocation patterns without asserting any particular policy on 
the
user. Escape analysis is the only solution I know to safely 
allow
pointers to be passed around without having to worry about how 
they

were allocated.
By contrast, I have no idea what you're suggesting, or how it's 
not a
'crutch'... but if it's anything to do with C++, I'm dubious, 
and

kinda frightened.


Incidentally, I've recently started a new C++ job, first C++ 
I've

written in some years... (after ~18 years, 12 professionally,
full-time C/C++)
After having adapted to D and distancing from C++, trying to go 
back

is like some form of inhuman torture!
I really don't remember it being as bad as it is... the time 
away has
given me new perspective on how terrible C++ is, and I can say 
with
confidence, there is NOTHING C++ could do to make itself a 
'better

option' at this point.
Judged on common ground, there is no competition. It's only 
'the devil
you know' case that I think can possibly make an argument for 
C++.


C++14 is quite nice and C++17 will be even better.

Then there is the advantage it is available in all OS vendors 
SDKs, with very nice tooling.


However, the hard reality in most corporations is that code bases 
will be pre-C++98 with its own set of guidelines, if any.



--
Paulo

Re: Why is `scope` planned for deprecation?

On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via 
Digitalmars-d wrote:
I don't follow how you associate that opinion with 
implementation of

scope.


I don't like semantics where I have to state that the parameters 
and the function should be pure. It should be opposite. Say, if 
you have an array on the stack, then I'd like to take a slice of 
it and send it to a function to compute a sum(). But, I don't 
want the type system to prevent me from doing it because the 
author of sum() forgot to add scope to the parameter.


What is the difference between a function that is annotated as 
pure and a function where all input is scope? This is 
backwards!


Function signatures should not say I am playing nice…, that 
should be the default. They should say watch out, I'm stealing 
your stuff!.


By contrast, I have no idea what you're suggesting, or how it's 
not a
'crutch'... but if it's anything to do with C++, I'm dubious, 
and

kinda frightened.


C++ is multi-paradigm and backwards compatible focused, and is 
therefore ruled by a mess of conventions and fixes, true.


After having adapted to D and distancing from C++, trying to go 
back is like some form of inhuman torture!


C++ is not excellent… Too verbose and grown out of the 
include/macro system (which suits C better than C++). I find C++ 
ok when I use it like C with bells (and leave out the whistles).


Judged on common ground, there is no competition. It's only 
'the devil you know' case that I think can possibly make an

argument for C++.


I don't know. I only use C++ for things that is suitable for C. 
Like DSP/realtime. Fortunately I don't have to deal with other 
people's C++ code.


Many C++ frameworks look really ugly, but with C++14 I think I 
shall be able to make my own code look acceptable (readable).

Re: Why is `scope` planned for deprecation?

2014-11-13 Thread Wyatt via Digitalmars-d

On Thursday, 13 November 2014 at 12:01:33 UTC, Ola Fosheim 
Grøstad wrote:


I don't like semantics where I have to state that the 
parameters and the function should be pure. It should be 
opposite.


Unfortunately for your sanity, this isn't going to happen.  
Similarly unlikely is multiple pointer types, which Walter has 
repeatedly shot down.  I'd suggest bringing it back up if and 
when discussion of D3 begins in earnest.


-Wyatt

Re: Why is `scope` planned for deprecation?

On Thursday, 13 November 2014 at 12:01:33 UTC, Ola Fosheim 
Grøstad wrote:
On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via 
Digitalmars-d wrote:
I don't follow how you associate that opinion with 
implementation of

scope.


I don't like semantics where I have to state that the 
parameters and the function should be pure. It should be 
opposite. Say, if you have an array on the stack, then I'd like 
to take a slice of it and send it to a function to compute a 
sum(). But, I don't want the type system to prevent me from 
doing it because the author of sum() forgot to add scope to 
the parameter.


What is the difference between a function that is annotated as 
pure and a function where all input is scope? This is 
backwards!


Function signatures should not say I am playing nice…, that 
should be the default. They should say watch out, I'm stealing 
your stuff!.


I agree with this in principle, but it is unrealistic for D2. 
This is stuff that can go into a future D3, together with @safe 
by default, pure by default, and maybe immutable by default. But 
that doesn't mean that it shouldn't be introduced in D2 already, 
so that we can gain experience with it.


That said, it might not be so bad with `scope`. The latest 
iteration of the proposal has been simplified a lot; scope 
annotations will mostly be needed for function signatures, and 
explicit owners are only allowed there. There's also some 
potential for inference with templates.

Re: Why is `scope` planned for deprecation?

On 13 November 2014 22:01, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via Digitalmars-d wrote:

 I don't follow how you associate that opinion with implementation of
 scope.


 I don't like semantics where I have to state that the parameters and the
 function should be pure. It should be opposite. Say, if you have an array
 on the stack, then I'd like to take a slice of it and send it to a function
 to compute a sum(). But, I don't want the type system to prevent me from
 doing it because the author of sum() forgot to add scope to the parameter.

 What is the difference between a function that is annotated as pure and a
 function where all input is scope? This is backwards!

D has attribute inference, that's like, a thing now.
Theoretically, the compiler may be able to determine that a reference
does not escape, and infer the 'scope' attribute, in many cases. This
would be consistent with other attributes.


 Function signatures should not say I am playing nice…, that should be the
 default. They should say watch out, I'm stealing your stuff!.

But that's already a concrete pattern throughout D. To do something
otherwise would be an unexpected deviation from the norm.

For the record, I agree with you, but that boat sailed a very long
time ago. We must now stick to the pattern that's in place.


 Many C++ frameworks look really ugly, but with C++14 I think I shall be able
 to make my own code look acceptable (readable).

I don't see anything in C++11/14/17 that looks like they'll salvage
the language from the sea of barely decipherable template mess and
endless boilerplate. It seems they're getting deeper into that
madness, not less.
I spent the last 2 days doing some string processing in C++...
possibly the least fun I've ever had programming. Somehow I used to
find it tolerable!

Re: Why is `scope` planned for deprecation?

On 13 November 2014 21:54, Daniel Murphy via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 Manu via Digitalmars-d  wrote in message
 news:mailman.1926.1415879071.9932.digitalmar...@puremagic.com...

 Incidentally, I've recently started a new C++ job, first C++ I've
 written in some years... (after ~18 years, 12 professionally,
 full-time C/C++)
 After having adapted to D and distancing from C++, trying to go back
 is like some form of inhuman torture!
 I really don't remember it being as bad as it is... the time away has
 given me new perspective on how terrible C++ is, and I can say with
 confidence, there is NOTHING C++ could do to make itself a 'better
 option' at this point.
 Judged on common ground, there is no competition. It's only 'the devil
 you know' case that I think can possibly make an argument for C++.


 I know, it's easy to forget how bad C++ is to work with.  The new versions
 have fixed some of the pain points, but only some.

Yeah... nar. Not really. Every line of code is at least 3-4 times as
long as it needs to be. It's virtually impossible to see the code
through the syntactic noise.
I like nullptr, I can get behind that ;)

I realised within minutes that it's almost impossible to live without slices.
On the plus side, I've already made lots of converts in my new office
from my constant ranting :P

Re: Microsoft now giving away VS 2013

2014-11-13 Thread Wyatt via Digitalmars-d

On Thursday, 13 November 2014 at 08:50:29 UTC, Ola Fosheim 
Grøstad wrote:


So, how to write a source-to-source compiler from CS to D…? ;-)


I think it would be more useful would be to go the other way 
around for targeting Windows Phone.  Or rather, it would be if 
anyone actually used WP.  (Going after Microsoft's also-ran 
mobile OS isn't particularly compelling when our story for 
targeting Android is still in such a dire state.)


-Wyatt

Re: Microsoft now giving away VS 2013

2014-11-13 Thread bearophile via Digitalmars-d


Wyatt:


So, how to write a source-to-source compiler from CS to D…? ;-)


I think it would be more useful would be to go the other way 
around for targeting Windows Phone.


Perhaps it's better to make LDC2-LLVM output the intermediate 
code of the dotnet :-)


Bye,
bearophile

Re: Why is `scope` planned for deprecation?

On Thursday, 13 November 2014 at 10:38:57 UTC, Ola Fosheim 
Grøstad wrote:
On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz 
wrote:
Huh? That's exactly what _borrowing_ does. Ref-counting OTOH 
adds yet another reference type and thereby makes the 
situation worse.


I don't like explicit ref counting, but it is sometimes useful 
and I think Rust-style ownership is pretty close to unique_ptr 
which is ref-counting with a max count of 1… You can also view 
GC as being implicitly ref counted too (it is counted during 
collection).


I think I understand now how you want to use templates. You 
basically want to make the various reference types implement a 
protocol, and then templatize functions to accept any of those 
reference types, just like we do with ranges.


But this brings with it the downside of templates, namely 
template bloat. And you need to do additional work to eliminate 
all the redundant inc/dec calls if you pass an RC reference. All 
of which is unnecessary for most functions, because a function 
knows in advance whether it needs to retain the reference or just 
borrow it, and can be declared accordingly. This means that 
`scope` acts as an abstraction over the various reference types, 
be it GC, RC, plain pointer, unique pointer, or some more 
complicated user defined scheme.


This also benefits the GC, by the way. A scope reference doesn't 
need to be treated as a root, because there will always be at 
least one other copy of the reference. This means that structures 
containing only scoped references need not be scanned.





What does shared tell the compiler?


I guess you mean scope?


:)

It tells it retain no references after completion of this 
function. Like with pure, it should be opposite. You 
should tell the compiler I transfer ownership of this 
parameter. Then have a generic concept owned for 
parameters that is resolved using templates.


That's what deadalnix's proposal does. Though I don't quite 
see what templates have to do with it.


My understanding of Deadalnix' proposal is that owned objects 
can only reference other owned objects.


Yes. But they can also be merged into un-owned structures (i.e. 
the various heaps), at which point they lose their owned-ness. 
This allows the creator of these objects to be agnostic about how 
the consumers want to handle them.


I think region allocators do better if you start constraining 
relations by ownership.


Not sure what you mean, but I don't think region allocators can 
be used for this. They require the object creator to know in 
advance how long the objects will exist. Or alternatively, the 
creators need to be informed about that by receiving a reference 
to the region allocator, at which point we're most likely back at 
templates.

Re: Microsoft now giving away VS 2013

2014-11-13 Thread Paulo Pinto via Digitalmars-d


On Thursday, 13 November 2014 at 13:59:32 UTC, Wyatt wrote:
On Thursday, 13 November 2014 at 08:50:29 UTC, Ola Fosheim 
Grøstad wrote:


So, how to write a source-to-source compiler from CS to D…? ;-)


I think it would be more useful would be to go the other way 
around for targeting Windows Phone.  Or rather, it would be if 
anyone actually used WP.  (Going after Microsoft's also-ran 
mobile OS isn't particularly compelling when our story for 
targeting Android is still in such a dire state.)


-Wyatt


In Germany I get to see Lumias all the time in trains and in the 
southern countries there are more people with Lumias than iPhones.


--
Paulo

Re: On heap segregation, GC optimization and @nogc relaxing

2014-11-13 Thread Steven Schveighoffer via Digitalmars-d


On Wednesday, 12 November 2014 at 12:57:58 UTC, Marc Schütz wrote:

On Wednesday, 12 November 2014 at 06:48:47 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 03:13:20 UTC, Rikki 
Cattermole wrote:

[...]


yes and no. The ideas is similar, but it is not doable at 
library level if we want to get safety and the full benefit 
out of it, as it would require for the compiler to introduce 
some call to the runtime at strategic places and it does 
interact with @nogc.


I'm not sure. A library implementation may be feasible. For 
invalidation, the objects can be returned to their init state. 
This is safe, but maybe not ideal, as a compiler error might 
indeed be better. Even implicit conversion to shared  
immutable will be possible with multiple alias this, though 
it's worth discussing whether an explicit conversion isn't 
preferable.


As for @nogc, I see it as a clutch that's needed while no 
real solution is available, and as a tool for aiding 
transition once we have one.


That said, some compiler support will definitely be necessary.


I now remember that I played around with a related idea when 
Andrei suggested his template solution (but without the islands 
part):


http://wiki.dlang.org/User:Schuetzm/RC,_Owned_and_allocators

The important part is that owning, RC and GC types all need to 
know the allocators they belong to. In my example I need that to 
allow Owned types to be converted to RC types. In your proposal, 
something similar will ultimately be needed for merging the 
islands into specific heaps. The nice thing is that this scheme 
also allows for switching allocators on the fly at runtime, 
without template bloat, at the cost of virtual calls for using 
the allocators (which is probably an acceptable compromise for an 
inherently expensive thing like allocation).

Re: variable x cannot be read at compile time - how to get around this?


On 11/13/14 2:08 AM, Sergey wrote:

   Hello everyone!

I need to create a two-dimensional array in this way, for example:

auto x = 10;
auto y = 10;
auto some_array = new string[x][y];


auto some_array = new string[][](x, y);

Note, this creates 10 arrays of 10 elements all on the heap, and then a 
10 element array to point at them.


If you wanted an array of 10 *fixed sized* arrays (which is what your 
code was trying to do), then you need to have the first dimension be a 
compile-time constant such as a literal or an enum/immutable.


-Steve

Re: C++ overloaded operators and D

2014-11-13 Thread IgorStepanov via Digitalmars-d


On Thursday, 13 November 2014 at 09:57:04 UTC, Marc Schütz wrote:
On Wednesday, 12 November 2014 at 21:17:42 UTC, IgorStepanov 
wrote:
On Wednesday, 12 November 2014 at 20:49:42 UTC, Marc Schütz 
wrote:
On Wednesday, 12 November 2014 at 19:32:32 UTC, IgorStepanov 
wrote:
On Wednesday, 12 November 2014 at 14:41:17 UTC, Marc Schütz 
wrote:
On Wednesday, 12 November 2014 at 11:43:36 UTC, 
IgorStepanov wrote:
C++ and D provides different behaviour for operator 
overloading.
D has a opIndex + opIndexAssign overloads, and if we want 
to map opIndex to operator[], we must to do something with 
opIndexAssign.


operator[] can be mapped to opIndex just fine, right? Only 
opIndexAssign wouldn't be accessible from C++ via an 
operator, but that's because the feature doesn't exist. We 
can still call it via its name opIndexAssign.


operator and operator can't be mapped to D. Same for 
operator.


That's true. Maybe we can just live with pragma(mangle) for 
them, but use D's op... for all others?


Binary arithmetic operators can't be mapped to D, if them 
implemented as static functions:


Foo operator+(int a, Foo f); //unable to map it to D, 
because static module-level Foo opAdd(int, Foo) will not 
provide the same behaviour as operator+ in D.
Thus: C++ and D overloaded operators should live in 
different worlds.


Can't we map both static and member operators to opBinary 
resp. opBinaryRight members in this case? How likely is it 
that both are defined on the C++ side, and if they are, how 
likely is it that they will behave differently?


opBinary(Right) is a template-functions. You can't add 
previous declaration for it to struct:


//C++
struct Foo
{
 Foo operator+(const Foo);
};

Foo operator+(int, const Foo);

//D
extern(C++)
struct struct Foo
{
 Foo opBinary!+(const ref Foo); //???


I see...


}

Foo opBinary!+(int, const ref Foo); //???


But this would of course be opBinaryRight, and inside struct 
Foo.


What if
Foo operator+(const Bar, const Foo);?
Is it Foo.opBinaryRight, or Bar.opBinary, or both?


For a C++ class interfaced from D: opBinary() in whichever of 
the two classes it is defined.


For a D class interfaced from C++: choose one, preferably 
opBinary(), as it's the natural one.


It is too difficult, I think.
1. Compiler should generate static operator declaration (for 
linkage with C++) and method-wrapper.
2. We should use old non-template operators (like opAdd, opSub 
etc.) or introduce new kind of operators.
3. We should explain to the user how to use our operator bindings 
(explain to the user).


Anyway we may implement generic approach with pragma(mangle) now 
and add special rules for some operators if it be considered 
usefull. AFAIK, There are many objections aganist operators 
mapping are mentioned in n.g.

Re: Microsoft now giving away VS 2013

2014-11-13 Thread Wyatt via Digitalmars-d


On Thursday, 13 November 2014 at 14:17:43 UTC, Paulo  Pinto wrote:


In Germany I get to see Lumias all the time in trains and in 
the southern countries there are more people with Lumias than 
iPhones.


Oh?  Interesting; I'm honestly a bit surprised. (I see more 
Blackberry kit than WP in the US.)  Any observations relative to 
the prevalence of Android handsets?


-Wyatt

Re: Why is `scope` planned for deprecation?

2014-11-13 Thread Andrei Alexandrescu via Digitalmars-d


On 11/13/14 1:41 AM, bearophile wrote:

Andrei Alexandrescu:


I agree. This is one of those cases in which a good engineering
solution may be a lot better than the perfect solution (and linear
types are not even perfect...).


I am sure you are aware that the solution you are talking about is
rather more complex (for both final programmers and language
implementators) than the Rust solution.


In fact I am not! -- Andrei

Re: convert static arrays to dynamic arrays and return, have wrong data.

2014-11-13 Thread Nick Treleaven via Digitalmars-d


On 12/11/2014 15:36, Nick Treleaven wrote:

Seeing as the 'scope' attribute doesn't seem to be happening any time
soon, shouldn't the compiler reject static array slicing in @safe code?
The user is then forced to think about the operation, and put the code
in a @trusted delegate if they think it is actually safe.


This is:
https://issues.dlang.org/show_bug.cgi?id=8838

Apparently it's a bit tricky to implement ATM.

yebblies:

 This is not very easy, because the compiler lowers all static array
 assignment to slice assignment, making _every_ static array assignment
 unsafe.  That needs to be fixed first, and requires extensive changes 
 in the interpreter.


Steven Schveighoffer:

 Can you just ban slicing that escapes the statement?

Re: Microsoft now giving away VS 2013

2014-11-13 Thread MachineCode via Digitalmars-d


On Thursday, 13 November 2014 at 09:36:20 UTC, Paulo  Pinto wrote:
On Thursday, 13 November 2014 at 00:58:41 UTC, Walter Bright 
wrote:

http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/

This is good news for D! It lowers the bar for writing 64 bit 
D code on Windows, and it also enables us to abandon support 
for versions of VS prior to 2013.


Actually I think it makes the life harder to earn Windows 
developers hearts for D, specially with .NET Native around the 
corner (it will come in Windows 10).


Free Visual Studio + C#/F# + SIMD + .NET Native is a very 
enticing proposal.


I would have a very hard time to convince any of our customers 
to use D instead.


--
Paulo


Exactly my thoughts... also syntax sugar, compiled language was 
such a big argument to people use D instead of. But C# as an open 
source language (so the guys from UNIXes around can move to it) 
and native language, the C++ guys are going to move from C++ to 
C# not D. I don't know, but I'm not sure if this open source is 
good for D community.


And yeah I know there's Mono and it's open source from day 1. But 
it's the MS implementation.

Re: Microsoft now giving away VS 2013

2014-11-13 Thread MachineCode via Digitalmars-d

On Thursday, 13 November 2014 at 00:58:41 UTC, Walter Bright 
wrote:

http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/

This is good news for D! It lowers the bar for writing 64 bit D 
code on Windows, and it also enables us to abandon support for 
versions of VS prior to 2013.


I don't use neither VS for D nor dmd 64-bit compiler but Mono-D + 
dmd 32-bit instead of. Whay does means



enables us to abandon support for versions of VS prior to 2013


? why should you be supporting it before?

Re: Why is `scope` planned for deprecation?

2014-11-13 Thread Nick Treleaven via Digitalmars-d


On 12/11/2014 17:16, Marc Schütz schue...@gmx.net wrote:

On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven wrote:

For example, taking a mutable borrowed pointer for a variable means
you can't even *read* the original variable whilst the pointer lives.
I think no one would try to make D do that, but Rust's reason for
adding it is actually memory safety (I don't quite understand it, but
it involves iterator invalidation apparently). It's possible their
feature can be refined, but basically 'mut' in Rust really means
'unique'.


In my proposal, there's const borrowing. It still allows access to the
owner, but not mutation. This is necessary for safe implementation of
move semantics, and to guard against iterator invalidation. It also has
other uses, like the problems with transient range, e.g.
stdin.byLine(), which overwrite their buffer in popFront(). On the other
hand, it's opt-in; by default, owners are mutable while borrowed
references exist.


Looks good. Personally I've been meaning to study your (whole) proposal, 
I think its a valuable analysis of what problems we could/should solve.


Just from a quick look, I wonder if 'const borrowing' could solve the 
scoped!C premature destruction problem:


C c = std.typecons.scoped!C();
// memory for c has already been freed (need auto c = ...)

If the destruction of Scoped is disallowed whilst an (implicit alias 
this) borrow for c is alive, the compiler can generate an error.

Re: Why is `scope` planned for deprecation?

On Thursday, 13 November 2014 at 16:56:01 UTC, Nick Treleaven 
wrote:

On 12/11/2014 17:16, Marc Schütz schue...@gmx.net wrote:
On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven 
wrote:
For example, taking a mutable borrowed pointer for a variable 
means
you can't even *read* the original variable whilst the 
pointer lives.
I think no one would try to make D do that, but Rust's reason 
for
adding it is actually memory safety (I don't quite understand 
it, but
it involves iterator invalidation apparently). It's possible 
their
feature can be refined, but basically 'mut' in Rust really 
means

'unique'.


In my proposal, there's const borrowing. It still allows 
access to the
owner, but not mutation. This is necessary for safe 
implementation of
move semantics, and to guard against iterator invalidation. It 
also has

other uses, like the problems with transient range, e.g.
stdin.byLine(), which overwrite their buffer in popFront(). On 
the other
hand, it's opt-in; by default, owners are mutable while 
borrowed

references exist.


Looks good. Personally I've been meaning to study your (whole) 
proposal, I think its a valuable analysis of what problems we 
could/should solve.


Just from a quick look, I wonder if 'const borrowing' could 
solve the scoped!C premature destruction problem:


C c = std.typecons.scoped!C();
// memory for c has already been freed (need auto c = ...)

If the destruction of Scoped is disallowed whilst an (implicit 
alias this) borrow for c is alive, the compiler can generate an 
error.


Const borrowing is not even necessary for that. The problem with 
`std.typecons.scoped!C` is that it implicitly converts to `C`. 
Instead, it should only convert to `scope!this(C)`, then the 
assignment will be rejected correctly:


// ERROR: type mismatch: C != scope(C)
C c = std.typecons.scoped!C();
// ERROR: `c` outlives it's owner (temporary)
scope(C) c = std.typecons.scoped!C();
// OK: typeof(c) is now scoped!C
auto c = std.typecons.scoped!C();

Re: std.string import cleanup: how to fix regression?

2014-11-13 Thread Ilya Yaroshenko via Digitalmars-d


alias can not be deprecated :-(


What about:

static import std.algorithm : startsWith, endsWith, cmp, count;
static import std.array : join, split;

deprecated {
alias startsWith = std.algorithm.startsWith;
...
}

Re: std.string import cleanup: how to fix regression?

2014-11-13 Thread H. S. Teoh via Digitalmars-d

On Thu, Nov 13, 2014 at 07:27:57PM +, Ilya Yaroshenko via Digitalmars-d 
wrote:
 alias can not be deprecated :-(
 
 What about:
 
 static import std.algorithm : startsWith, endsWith, cmp, count;
 static import std.array : join, split;
 
 deprecated {
 alias startsWith = std.algorithm.startsWith;
 ...
 }

Maybe we should file an enhancement request to make alias deprecatable.
I know recently someone asked for the 'module' declaration to be
deprecatable, and it was implemented. Maybe it's time to extend that to
aliases too. :-)


T

-- 
There's light at the end of the tunnel. It's the oncoming train.

Re: std.string import cleanup: how to fix regression?

2014-11-13 Thread Robert burner Schadek via Digitalmars-d

On Thursday, 13 November 2014 at 19:27:59 UTC, Ilya Yaroshenko 
wrote:

alias can not be deprecated :-(


It can. But evidently, static import cannot be selective:

aa.d:
static import std.algorithm;// : startsWith, endsWith, cmp, 
count;

static import std.array;// : join, split;

deprecated {
alias startsWith = std.algorithm.startsWith;
}

bb.d:
import aa;
bool test() {
return .startsWith();
}

# dmd -c bb.d
bb.d(2): Deprecation: alias aa.startsWith is deprecated

Remove ;// to enable the selective imports, and we get errors:
aa.d(1): Error: static import std cannot have an import bind list
aa.d(1): Error: static import __anonymous cannot have an import 
bind list
aa.d(1): Error: static import __anonymous cannot have an import 
bind list
aa.d(1): Error: static import __anonymous cannot have an import 
bind list

aa.d(2): Error: static import std cannot have an import bind list
aa.d(2): Error: static import __anonymous cannot have an import 
bind list


This seems like an arbitrary restriction. [1] states that it is 
disallowed (under the heading Selective Imports), but gives no 
justification. It's probably because of the implementation.


Anyway, the imports can be pulled into the `deprecated` block to 
make the intention clear:


deprecated {
static import std.algorithm;
static import std.array;

alias startsWith = std.algorithm.startsWith;
}


[1] http://dlang.org/module

Re: std.experimental.logger formal review round 3

IMO this defeats the design goal off having the default case very 
easy and just working. Therefore, I think thread local global 
Logger and how to make them interact is something that should be 
left to the advanced user.

Re: std.experimental.logger formal review round 3

2014-11-13 Thread Robert burner Schadek via Digitalmars-d

On Wednesday, 12 November 2014 at 15:05:29 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 12 November 2014 at 12:39:24 UTC, Robert burner 
Schadek wrote:
Only one thread can write to one Logger at a time, also known 
as synchronization. Anything else is properly wrong. But you 
can have as many Logger as you have memory.


Taking a lock when the logging call doesn't flush to disk 
sounds rather expensive.


If you log to a FileLogger it will flush. It is just a costly 
thing to do. There is no way get the work done but doing it.

Re: Why is `scope` planned for deprecation?

On Thursday, 13 November 2014 at 13:46:20 UTC, Manu via 
Digitalmars-d wrote:

On 13 November 2014 22:01, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via 
Digitalmars-d wrote:

D has attribute inference, that's like, a thing now.


Yes, these days D arguments go like this:

A: I am saying no because it would go against separate 
compilation units.


B: I am saying yes because we have attribute inference.

A: But when will it be implemented?

B: After we have resolved all issues in the bugtracker.

A: But C++17 will be out by then!

B: Please don't compare D to C++, it is a unique language

A: And Rust will be out too!

B: Hey, that's a low blow. And unfair! Besides, linear types 
suck.


A: But 'scope' is a linear type qualifier, kinda?

B: Ok, we will only do it as a library type then.

A: How does that improve anything?

B: It changes a lot, it means Walter can focus on ironing out 
bugs and Andrei will implement it after he has fixed the GC.


A: When will that happen?

B: After he is finished with adding ref counters to Phobos

A: I thought that was done?

B: Don't be unreasonable, Phobos is huge, it takes at least 6 
months! Besides, it is obvious that we need to figure out how to 
do scope before completing ref counting anyway.


A: I agree…Where were we?

B: I'm not sure. I'll try to find time to write a DIP.


I don't see anything in C++11/14/17 that looks like they'll 
salvage
the language from the sea of barely decipherable template mess 
and

endless boilerplate. It seems they're getting deeper into that
madness, not less.


Stuff like auto on return types etc makes it easier and less 
verbose when dealing with templated libraries.


Unfortunately, I guess I can't use it on my next project anyway, 
since I need to support iOS5.1 which probably means XCode… 4? 
Sigh…


That's one of the things that annoy me with C++, the long tail 
for being able to use the new features.



I spent the last 2 days doing some string processing in C++...
possibly the least fun I've ever had programming. Somehow I 
used to

find it tolerable!


Ack… I try to stick to binary formats. Strings are only fun in 
languages like Python (and possibly Haskell).

Re: On heap segregation, GC optimization and @nogc relaxing

2014-11-13 Thread Robert burner Schadek via Digitalmars-d


On Thursday, 13 November 2014 at 10:10:34 UTC, Marc Schütz wrote:

On Wednesday, 12 November 2014 at 21:15:05 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 12:49:41 UTC, Marc Schütz 
wrote:
All this is unfortunately only true if there are no 
references between heaps, i.e. if the heaps are indeed 
islands. Otherwise, there need to be at least write 
barriers.




Yes, that is exactly why I'm listing the case where these can 
be created in @safe code and propose a solution to plug the 
hole (and which brings other benefits along the road).


Hmm... I can't find that in what you wrote. To clarify: I'm 
talking about the fact that, for example, a thread-local heap 
can contain references into the immutable and shared heaps. 
Therefore, the immutable heap can _not_ be collected without 
disturbing any threads, because any TL heaps (and stacks!) can 
potentially have references to it. They either need to be 
stopped, or write barriers need to be utilized when references 
to immutable data are changed.


You need a set of root from the TL heap. The trick being to
consider everything that is allocated AFTER you get the roots as
automatically alive (you'll collect this in the next collection
cycle).

That way, new allocated chunk that have reference in the TL heap
will be kept alive, even if you don't know about the roots.

You'll find plenty of information about the details if look into
GC for ML family languages.

Re: std.experimental.logger formal review round 3

2014-11-13 Thread Marco Leise via Digitalmars-d

Am Wed, 12 Nov 2014 17:56:06 +
schrieb Dicebot pub...@dicebot.lv:

 […] have means to 
 explicitly capture lock on global one from local proxies for 
 optimized bulk logging.

That's certainly something that occurred to me when talking
with Manu about logging. A locked bulk transfer could
be added, maybe replacing the single element transfer function
that exists already. Thread local loggers that accumulate logs
and pass them on to a global logger seem to be a well known
use case.

-- 
Marco

Re: std.experimental.logger formal review round 3


On Thursday, 13 November 2014 at 22:13:53 UTC, Marco Leise wrote:

Am Wed, 12 Nov 2014 17:56:06 +
schrieb Dicebot pub...@dicebot.lv:

[…] have means to explicitly capture lock on global one from 
local proxies for optimized bulk logging.


That's certainly something that occurred to me when talking
with Manu about logging. A locked bulk transfer could
be added, maybe replacing the single element transfer function
that exists already. Thread local loggers that accumulate logs
and pass them on to a global logger seem to be a well known
use case.


One bad thing about that is that the global log is no longer 
sorted by time if you write to any file. That would make using 
the log much more difficult IMO.

Re: On heap segregation, GC optimization and @nogc relaxing

2014-11-13 Thread Joseph Rushton Wakeling via Digitalmars-d


On Thursday, 13 November 2014 at 14:26:44 UTC, Marc Schütz wrote:
The important part is that owning, RC and GC types all need to 
know the allocators they belong to. In my example I need that 
to allow Owned types to be converted to RC types. In your 
proposal, something similar will ultimately be needed for 
merging the islands into specific heaps. The nice thing is that 
this scheme also allows for switching allocators on the fly at 
runtime, without template bloat, at the cost of virtual calls 
for using the allocators (which is probably an acceptable 
compromise for an inherently expensive thing like allocation).


If you have a owned type, you don't need a builtin RC type. As
long as the wrapper that implement the RC own the RCed object,
everything is safe.

Also, this construct as the nice side effect that a single
reference count can own a whole island instead of tracking all
objects RC one by one.

Re: Microsoft now giving away VS 2013


On 13/11/14 10:36, Paulo Pinto via Digitalmars-d wrote:

Actually I think it makes the life harder to earn Windows developers hearts for
D, specially with .NET Native around the corner (it will come in Windows 10).

Free Visual Studio + C#/F# + SIMD + .NET Native is a very enticing proposal.


I don't think there's any point in worrying about this.  Microsoft open-sourcing 
.NET and making Visual Studio freely available is a great contribution to 
software development.  Rather than worrying about whether it will take away 
opportunities from D, we should just focus on making D as good as it can be and 
solving the problems of the people who find it compelling.

Re: Microsoft now giving away VS 2013

2014-11-13 Thread Trass3r via Digitalmars-d

On Thursday, 13 November 2014 at 09:36:26 UTC, Manu via 
Digitalmars-d wrote:

On 13 November 2014 10:57, Walter Bright wrote:
This is good news for D! It lowers the bar for writing 64 bit 
D code on
Windows, and it also enables us to abandon support for 
versions of VS prior

to 2013.


Many, many corporate VS users get stuck on legacy versions of 
VS for a
very long time. We still use VS2010 at work for instance, with 
no plan to upgrade.
It would be a shame to lose legacy VS support, but I think the 
focus should certainly emphasise these future releases.


It's perfectly possible to install newer versions side-by-side 
and even combine the new IDE with the old crap compiler for 
transitioning, which I've done since the very first CTP.
Starting with 2013 the express editions are also fully usable and 
only lack plugin support.

The rest is just excuses.

Re: Why is `scope` planned for deprecation?


On Thursday, 13 November 2014 at 10:32:05 UTC, Manu via
Digitalmars-d wrote:

I don't think this proposal has issues with that.
The thing at the root of the call tree is the 'owner'. Nothing 
can
escape a scope call-tree, so the owner or allocation policy 
doesn't

matter, and that's the whole point.


That is way to define ownerhsip so that is not a rebutal of my
comment. This makes assumption about ownership, that we may or
may not want;

I think the proposal is sound overall (I haven't try to explore
all special cases scenarios, so it is a reserved yes for now) but
going forward with this before defining ownership is not a good
approach.

Re: Microsoft now giving away VS 2013

2014-11-13 Thread ZombineDev via Digitalmars-d

Well D is still a much better language. I have used C#
professionally for about 2 years and in my opinion it invites
writing over-architected OOP with little regard about efficiency.
My experience is based on working in the code-base of my old job,
reading forums, books and so on.

Just look at these beautiful pieces of art:

http://referencesource.microsoft.com/#PresentationFramework/Framework/System/Windows/Controls/DataGrid.cs
^ just try to find were the performance bottleneck is and
refactor it :D

And some other elegant pieces:
https://github.com/dotnet/corefx/blob/master/src/System.Numerics.Vectors/src/System/Numerics/Register.cs

https://github.com/dotnet/corefx/blob/master/src/System.Numerics.Vectors/src/System/Numerics/Vector.cs

^ Without templates and CTFE the power to weight ratio is pretty
low.

Of course there are exceptions to the rule. Here is a somewhat
large, performance oriented project. This an open-source
implementation of the classic CC RTS games:

https://github.com/OpenRA/OpenRA

I really don't want to go back to .NET. It's not about that
Microsoft is evil, anti-FOSS or anything like that.
I just really like the way D allows me to express my intent and
how flexible it is. It is the overall feeling I get from the
community that people want to use D to write elegant, yet highly
optimal code. And when there is a problem preventing this (like
for some people the GC) a great effort is made to improve the
situation (e.g. http://wiki.dlang.org/DIPs, etc. )

My impression is that the average .net developer is scared by the
low-level stuff and wants these stuff to be magically taken
care of. I haven't seen anyone that wants to get rid of the GC
and even fewer are trying to be proactive and to find a solution
(like @nogc, RC strings or exceptions in Dland).

Also a large portion C# devs are highly dependent on Microsoft's
politics. Like when the development of Silverlight platform was
canceled. It was a huge blow to the .NET community and there was
no solution (even third-party) so everyone just the left the
sinking ship.

Re: Microsoft now giving away VS 2013

2014-11-13 Thread Nick Sabalausky via Digitalmars-d


On 11/13/2014 10:38 AM, Wyatt wrote:


Oh?  Interesting; I'm honestly a bit surprised. (I see more Blackberry
kit than WP in the US.)


I've never seen a blackberry in the US. Although I've only ever seen one 
person with a windows phone, and that person switched to android soon after.

Re: Why is `scope` planned for deprecation?


On Thursday, 13 November 2014 at 13:46:20 UTC, Manu via
Digitalmars-d wrote:

D has attribute inference, that's like, a thing now.
Theoretically, the compiler may be able to determine that a 
reference
does not escape, and infer the 'scope' attribute, in many 
cases. This

would be consistent with other attributes.



Yes, that is the only sane road forward.

Re: On heap segregation, GC optimization and @nogc relaxing


On 11/11/2014 6:34 PM, deadalnix wrote:

On an implementation level, a call to a pure function that return an owned could
look like this :

{
   IslandID __saved = gc_switch_new_island();
   scope(exit) gc_restore_island(__saved);

   call_pure_function();
}

This allow us to rely much less on the GC and allow for a better GC 
implementation.


If that wrapper is automatically generated by the compiler, so the user doesn't 
have to mess with it, it could be workable.

Scope and Ref and Borrowing

Thought I'd bring this up as deadalnix is working on a related proposal. It uses 
'scope' in conjunction with 'ref' to resolve some long standing @safe issues.

---

**Background

The goal of @safe code is that it is guaranteed to be memory safe. This is 
mostly
achieved, but there's a gaping hole - returning pointers to stack objects when 
those
objects are out of scope. This is memory corruption.

The simple cases of this are disallowed:

  T* func(T t) {
T u;
return t; // Error: escaping reference to local t
return u; // Error: escaping reference to local u
  }

But are is easily circumvented:

  T* func(T t) {
T* p = t;
return p;  // no error detected
  }

@safe deals with this by preventing taking the address of a local:

  T* func(T t) @safe {
T* p = t; // Error: cannot take address of parameter t in @safe function 
func
return p;
  }

But this is awfully restrictive. So the 'ref' storage class was introduced which
defines a special purpose pointer. 'ref' can only appear in certain contexts,
in particular function parameters and returns, only applies to declarations,
cannot be stored, and cannot be incremented.

  ref T func(T t) @safe {
return t; // Error: escaping reference to local variable t
  }

Ref can be passed down to functions:

  void func(ref T t) @safe;
  void bar(ref T t) @safe {
 func(t); // ok
  }

But the following idiom is far too useful to be disallowed:

  ref T func(ref T t) @safe {
return t; // ok
  }

And if it is misused it can result in stack corruption:

  ref T foo() @safe {
T t;
return func(t); // no error detected, despite returning pointer to t
  }

The purpose of this proposal is to detect these cases at compile time and 
disallow them.
Memory safety is achieved by allowing pointers to stack objects be passed down 
the stack,
but those pointers may not be saved into non-stack objects or stack objects 
higher on the stack,

and may not be passed up the
stack past where they are allocated.

The:

return func(t);

case is detected by all of the following conditions being true:

1. foo() returns by reference
2. func() returns by reference
3. func() has one or more parameters that are by reference
4. 1 or more of the arguments to those parameters are stack objects local to 
foo()
5. Those arguments can be @safe-ly converted from the parameter to the return 
type.
   For example, if the return type is larger than the parameter type, the 
return type

   cannot be a reference to the argument. If the return type is a pointer, and 
the
   parameter type is a size_t, it cannot be a reference to the argument. The 
larger
   a list of these cases can be made, the more code will pass @safe checks 
without requiring

   further annotation.

**Scope Ref

The above solution is correct, but a bit restrictive. After all, func(t, u) 
could be returning
a reference to non-local u, not local t, and so should work. To fix this, 
introduce the concept

of 'scope ref':

ref T func(scope ref T t, T u) @safe {
  return t; // Error: escaping scope ref t
  return u; // ok
}

Scope means that the ref is guaranteed not to escape.

  T u;
  ref T foo() @safe {
T t;
return func(t, u); // ok, u is not local
return func(u, t); // Error: escaping scope ref t
  }

This scheme minimizes the number of 'scope' annotations required.

**Out Parameters

'out' parameters are treated like 'ref' parameters for the purposes of this 
document.


**Inference

Many functions can infer pure, @safe, and @nogc. Those same functions can infer
which ref parameters are 'scope', without needing user annotation.

**Mangling

Scope will require additional name mangling, as it affects the interface of the 
function.


**Nested Functions

Nested functions have more objects available than just their arguments:

  ref T foo() @safe {
T t;
ref T func() { return t; }
return func();  // should be disallowed
  }

On the plus side the body of the nested function is available to the compiler 
for
examination.

**Delegates and Closures

This one is a little harder; but the compiler can detect that t is taken by 
reference,

and then can assume that dg() is returning t by reference and disallow it.

  ref T foo() @safe {
T t;
ref T func() { return t; }
auto dg = func;
return dg();  // should be disallowed
  }


**Overloading

Scope does not affect overloading, i.e.:

   T func(scope ref a);
   T func(ref T b);

are considered the same as far as overloading goes.

**Inheritance

Overriding functions inherit any 'scope' annotations from their antecedents.

**Limitations

Arrays of references are not allowed.
Struct and class fields that are references are not allowed.
Non-parameter variables cannot be references.

Re: Why is `scope` planned for deprecation?

On 14 November 2014 09:28, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On Thursday, 13 November 2014 at 10:32:05 UTC, Manu via
 Digitalmars-d wrote:

 I don't think this proposal has issues with that.
 The thing at the root of the call tree is the 'owner'. Nothing can
 escape a scope call-tree, so the owner or allocation policy doesn't
 matter, and that's the whole point.


 That is way to define ownerhsip so that is not a rebutal of my
 comment. This makes assumption about ownership, that we may or
 may not want;

 I think the proposal is sound overall (I haven't try to explore
 all special cases scenarios, so it is a reserved yes for now) but
 going forward with this before defining ownership is not a good
 approach.

I'm super happy your on board with this. You're often a hard sell :)

What about the definition of 'ownership' do you find problematic?
It's clear we're not going to get multiple pointer types (read: owner
types) like in Rust... so then ownership strategy will probably remain
fairly arbitrary.

The point of scope seems to be precisely to set the problem of
ownership aside. That leaves ownership at the root of the call-tree to
remain being managed however the user likes.

Once we have scope, then we can have meaningful implementations of
things like a unique pointer, and finally approach efficient RC.
Personally, it has proven to be the most inhibiting barrier to further
development in most areas I care about left.

Re: variable x cannot be read at compile time - how to get around this?

2014-11-13 Thread Sergey via Digitalmars-d

On Thursday, 13 November 2014 at 14:27:32 UTC, Steven 
Schveighoffer wrote:

On 11/13/14 2:08 AM, Sergey wrote:

  Hello everyone!

I need to create a two-dimensional array in this way, for 
example:


auto x = 10;
auto y = 10;
auto some_array = new string[x][y];


auto some_array = new string[][](x, y);

Note, this creates 10 arrays of 10 elements all on the heap, 
and then a 10 element array to point at them.


If you wanted an array of 10 *fixed sized* arrays (which is 
what your code was trying to do), then you need to have the 
first dimension be a compile-time constant such as a literal or 
an enum/immutable.


-Steve


Thanks!!!
This is what I need!
auto some_array = new string[][](x, y);

Re: Scope and Ref and Borrowing

On 14 November 2014 11:20, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 Thought I'd bring this up as deadalnix is working on a related proposal. It
 uses 'scope' in conjunction with 'ref' to resolve some long standing @safe
 issues.
 ---

 **Background

 The goal of @safe code is that it is guaranteed to be memory safe. This is
 mostly
 achieved, but there's a gaping hole - returning pointers to stack objects
 when those
 objects are out of scope. This is memory corruption.

 The simple cases of this are disallowed:

   T* func(T t) {
 T u;
 return t; // Error: escaping reference to local t
 return u; // Error: escaping reference to local u
   }

 But are is easily circumvented:

   T* func(T t) {
 T* p = t;
 return p;  // no error detected
   }

 @safe deals with this by preventing taking the address of a local:

   T* func(T t) @safe {
 T* p = t; // Error: cannot take address of parameter t in @safe
 function func
 return p;
   }

 But this is awfully restrictive. So the 'ref' storage class was introduced
 which
 defines a special purpose pointer. 'ref' can only appear in certain
 contexts,
 in particular function parameters and returns, only applies to declarations,
 cannot be stored, and cannot be incremented.

   ref T func(T t) @safe {
 return t; // Error: escaping reference to local variable t
   }

 Ref can be passed down to functions:

   void func(ref T t) @safe;
   void bar(ref T t) @safe {
  func(t); // ok
   }

 But the following idiom is far too useful to be disallowed:

   ref T func(ref T t) @safe {
 return t; // ok
   }

 And if it is misused it can result in stack corruption:

   ref T foo() @safe {
 T t;
 return func(t); // no error detected, despite returning pointer to t
   }

 The purpose of this proposal is to detect these cases at compile time and
 disallow them.
 Memory safety is achieved by allowing pointers to stack objects be passed
 down the stack,
 but those pointers may not be saved into non-stack objects or stack objects
 higher on the stack,
 and may not be passed up the
 stack past where they are allocated.

 The:

 return func(t);

 case is detected by all of the following conditions being true:

 1. foo() returns by reference
 2. func() returns by reference
 3. func() has one or more parameters that are by reference
 4. 1 or more of the arguments to those parameters are stack objects local to
 foo()
 5. Those arguments can be @safe-ly converted from the parameter to the
 return type.
For example, if the return type is larger than the parameter type, the
 return type
cannot be a reference to the argument. If the return type is a pointer,
 and the
parameter type is a size_t, it cannot be a reference to the argument. The
 larger
a list of these cases can be made, the more code will pass @safe checks
 without requiring
further annotation.

 **Scope Ref

 The above solution is correct, but a bit restrictive. After all, func(t, u)
 could be returning
 a reference to non-local u, not local t, and so should work. To fix this,
 introduce the concept
 of 'scope ref':

 ref T func(scope ref T t, T u) @safe {
   return t; // Error: escaping scope ref t
   return u; // ok
 }

 Scope means that the ref is guaranteed not to escape.

   T u;
   ref T foo() @safe {
 T t;
 return func(t, u); // ok, u is not local
 return func(u, t); // Error: escaping scope ref t
   }

 This scheme minimizes the number of 'scope' annotations required.

 **Out Parameters

 'out' parameters are treated like 'ref' parameters for the purposes of this
 document.

 **Inference

 Many functions can infer pure, @safe, and @nogc. Those same functions can
 infer
 which ref parameters are 'scope', without needing user annotation.

 **Mangling

 Scope will require additional name mangling, as it affects the interface of
 the function.

 **Nested Functions

 Nested functions have more objects available than just their arguments:

   ref T foo() @safe {
 T t;
 ref T func() { return t; }
 return func();  // should be disallowed
   }

 On the plus side the body of the nested function is available to the
 compiler for
 examination.

 **Delegates and Closures

 This one is a little harder; but the compiler can detect that t is taken by
 reference,
 and then can assume that dg() is returning t by reference and disallow it.

   ref T foo() @safe {
 T t;
 ref T func() { return t; }
 auto dg = func;
 return dg();  // should be disallowed
   }


 **Overloading

 Scope does not affect overloading, i.e.:

T func(scope ref a);
T func(ref T b);

 are considered the same as far as overloading goes.

 **Inheritance

 Overriding functions inherit any 'scope' annotations from their antecedents.

 **Limitations

 Arrays of references are not allowed.
 Struct and class fields that are references are not allowed.
 Non-parameter variables cannot

Re: convert static arrays to dynamic arrays and return, have wrong data.

2014-11-13 Thread Daniel Murphy via Digitalmars-d

Nick Treleaven  wrote in message news:m42lbb$2pru$1...@digitalmars.com... 


This is:
https://issues.dlang.org/show_bug.cgi?id=8838

Apparently it's a bit tricky to implement ATM.

yebblies:

  This is not very easy, because the compiler lowers all static array
  assignment to slice assignment, making _every_ static array assignment
  unsafe.  That needs to be fixed first, and requires extensive changes 
  in the interpreter.


I think the situation has slightly improved since.

New std.range submodule

2014-11-13 Thread H. S. Teoh via Digitalmars-d

Recently, some good progress has been made in cleaning up the messy web
of imports between Phobos modules, so that importing one module for a
single function won't also pull in half of Phobos. Part of this work has
been to separate the range API constraints (isInputRange, hasLength,
isForwardRange, etc.) from std.range into a new submodule currently
named std.range.constraints.

However, we are considering renaming it to a better name, because
currently it also contains a bunch of stuff that are *not* constraints
per se -- such as the range primitives for built-in arrays. They were
put there because they are often used together with the range API
constraints, and any code that uses them would also need to import the
constraints anyway.

Any ideas for a better name for this submodule? We'd like to get this
decided before the next release, after which it will be more troublesome
to rename it.

Possible alternatives include:

- std.range.core
- std.range.api
- etc.

Any other suggestions?


T

-- 
Without outlines, life would be pointless.

Re: Scope and Ref and Borrowing


On 11/13/2014 7:41 PM, Manu via Digitalmars-d wrote:

I'm not quite clear; are you suggesting 'scope ref' would be a storage
class?


Yes.


(looks like it, but it also affects mangling?)


Only for function types.


Please, consider Marc Schütz's existing proposal.
Please, please, don't make scope a storage class.


Got a handy link to it?


I have a lot of other issues with this proposal, but maybe I
misunderstand it in principle...?


I have no idea what your other issues are and what they may be based on :-)

Re: Scope and Ref and Borrowing


On 11/13/2014 9:36 PM, Walter Bright wrote:

Got a handy link to it?


Found it:

http://wiki.dlang.org/User:Schuetzm/scope

Re: New std.range submodule

2014-11-13 Thread Rikki Cattermole via Digitalmars-d


On 14/11/2014 6:30 p.m., H. S. Teoh via Digitalmars-d wrote:

Recently, some good progress has been made in cleaning up the messy web
of imports between Phobos modules, so that importing one module for a
single function won't also pull in half of Phobos. Part of this work has
been to separate the range API constraints (isInputRange, hasLength,
isForwardRange, etc.) from std.range into a new submodule currently
named std.range.constraints.

However, we are considering renaming it to a better name, because
currently it also contains a bunch of stuff that are *not* constraints
per se -- such as the range primitives for built-in arrays. They were
put there because they are often used together with the range API
constraints, and any code that uses them would also need to import the
constraints anyway.

Any ideas for a better name for this submodule? We'd like to get this
decided before the next release, after which it will be more troublesome
to rename it.

Possible alternatives include:

- std.range.core
- std.range.api
- etc.

Any other suggestions?


T


std.range.checks

I use this naming scheme for modules (with their purpose) for heavy ctfe 
code.

Checks are:
1. Free functions
2. Expected to run at compile time only
3. Pure
4. Are templated

Helpers are:
1. Free functions
2. Expected to run at runtime
3. Not pure
4. May or may not be templated

Re: Why is `scope` planned for deprecation?

On Friday, 14 November 2014 at 03:20:42 UTC, Manu via 
Digitalmars-d wrote:
I'm super happy your on board with this. You're often a hard 
sell :)


What about the definition of 'ownership' do you find 
problematic?


I don't find it problematic. However, the concept of burrowing 
(what we do with scope in that proposal) makes assumptions about 
ownership. So I'd like to see ownership addressed.


Ultimately, we can decide that ownership is loosely defined, but 
that may have very important consequences on the possibility - or 
not - to introduce ownership. I think ownership is an important 
concept to have to get the gc world and the non gc worlds 
interact nicely (which should be a big interest of yours as well).


It's clear we're not going to get multiple pointer types (read: 
owner
types) like in Rust... so then ownership strategy will probably 
remain

fairly arbitrary.



I think it make sense to have something for ownership. The error 
of rust wasn't going that road, but going in that road 100%, 
which come at a cost at interface level which is too important. A 
simpler ownership system, that fallback on the GC or unsafe 
feature when it fall short.


I'm confident at this point that we can get most of the benefit 
of an ownership system with something way simpler than rust's 
system if you accept to not cover 100% of the scenarios.


Once we have scope, then we can have meaningful implementations 
of

things like a unique pointer, and finally approach efficient RC.
Personally, it has proven to be the most inhibiting barrier to 
further

development in most areas I care about left.


Yes, that is absolutely necessary to have safe RC, and a great 
tool to make it more efficient.


I'm not fan of unique as this is, IMO, a dumbed down version of 
what ownership can be, with no real upside.

Re: On heap segregation, GC optimization and @nogc relaxing