[Issue 15027] cannot pass arguments of type DirEntry to std.file functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15027

--- Comment #15 from Rainer Schuetze  ---
>Check this out:
>https://github.com/D-Programming-Language/phobos/pull/3694

This is pretty much the workaround given by Kenji above. It has the downside
that you have to copy the full DirEntry object to the stack as a function
argument. Not a big issue for DirEntry, but it can be pretty bad if the struct
has an expensive postblit or if it is disabled.

--

Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.069.0.html

Please report any bugs at https://issues.dlang.org

-Martin

Re: D and microservices

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 7 October 2015 at 17:31:12 UTC, Atila Neves wrote:
My "Go vs D vs C vs Erlang" MQTT shootout was based on a 
colleague claiming that Go would win because concurrency is its 
thing. I called his bluff since despite Go having a (AFAIK) 
very good scheduler, I didn't see how vibe.d wouldn't give me 
the same performance. I was right.


Yes, Go is unlikely to have any throughput advantages compared to 
a systems level programming language.


Go's advantages:
- a more mature compiler
- robust runtime features
- lower latency GC
- infrastructure support
- simple syntactical constructs

I would consider Go-routines a convenience feature.

If C++17 does stackless coroutines right then it probably will 
surpass both Go and D in terms of memory locality, initialization 
performance and memory usage; and therefore throughput as well.

Re: D and microservices

[extrawurst via Digitalmars-d]

On Tuesday, 6 October 2015 at 17:54:48 UTC, Russel Winder wrote:
On Tue, 2015-10-06 at 16:21 +, Dejan Lekic via 
Digitalmars-d wrote:
On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder 
wrote:

> [...]

As far as I know, there is no implementation of microservices 
as we see in the Java world. IMHO, D community should come up 
with a good microservices architecture. As you pointed out, it 
could be based on vibed.


Pity, microservices is a very fashionable thing just now, and 
Go is wiping the floor with Node and Java. Well that bit is 
opinion but… many people are getting into all this 
non-blocking, event-driven, shared memory stuff and boiling 
their brains, whereas the Go folk are doing blocking stuff 
using dataflow which is much easier to program.


I have never used Go, but isn't what you describe exactly what 
vibe.d is doing using Fibers ?

[Issue 15170] New: default arguments from expression tuple don't work

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15170

  Issue ID: 15170
   Summary: default arguments from expression tuple don't work
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

alias Tuple(Stuff...) = Stuff;
void foo(Tuple!(int, float) args = Tuple!(1, 2f)) {}
void main()
{
foo(1, 2); /* accepted */
foo(); /* Error: function test.foo (int _param_0, float _param_1) is not
callable using argument types () */
}

--

DSFML reaches version 2.1

[Jeremy DeHaan via Digitalmars-d-announce]

It is my pleasure to announce that DSFML hit version 2.1! This 
version has been a long time coming, but this represents a huge 
milestone for DSFML (and for me!)


DSFML(along with its backend DSFMLC) is a binding and a wrapper 
for SFML - the Simple and Fast Multimedia Library. It does 
input(mouse, keyboard, joysticks/gamepads), audio (buffered 
playback, streamed playback, recording), networking(tcp/udp 
sockets, ftp, http), window and OpenGL context creation, and 
simple 2D graphics using OpenGL (sprites, text, shapes, shaders, 
and vertex arrays). Currently works on Linux, Windows, and OS X.


Reasons that this took so long was:
- Many bug fixes
- Finally passed all included unit tests
- Things make more sense
- Created a website
- Added documentation
- Added tutorials
- School's a bitch

Visit the website at http://dsfml.com to view tutorials, 
documentation, forum, and downloads.


Just a heads up, I have never gotten a project to a point like 
this. I have never had to put a website or tutorials together for 
anything, and this is the first "real" release. I'm sure some 
things don't make as much sense as I think they do. Go easy on me 
;)


Plans for the future:
- Make things more idiomatic to D
- Update to most recent version of SFML
- Better everything (tests, documentation, tutorials, website)

Check it out, have fun, and most importantly let me know if you 
have issues!


https://github.com/Jebbs/DSFML
https://github.com/Jebbs/DSFMLC
http://code.dlang.org/packages/dsfml

Re: D 2015/2016 Vision?

[Paulo Pinto via Digitalmars-d]

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis 
wrote:

On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis 
wrote:
I'm not sure what else I can say. The example I posted says 
it all, and it can't be done properly in D (or C#, but why 
lower the bar because of their mistakes? ;)


It's a side effect of having the lifetime of an object managed 
by the GC. There's no way around that except to use something 
else like manual memory management or reference counting.


You are literally repeating what I just said in different words.

in D, it's a good reason to use structs to manage resources 
like that, and since most objects really have no need of 
inheritance and have no business being classes, it's usually 
fine.


This is an opinion.

I want polymorphism AND deterministic destruction, and the 
least you could do is just admit that it's a downside to D not 
having it, instead of trying to tell me that everything I know 
is wrong..


But in the cases where you do have to use a class, it can get 
annoying.


YES, its does, and it's not just an odd case here and there..

You simply do not rely on the GC or the destruction of the 
object to free system resources. You manually call a function 
on the object to free those resources when you're done with it.


I'm sorry, but I almost can't believe you're saying this.

So, you're saying you want me to just revert back to manual 
resource management and accept that huge resources like 
textures and such may just leak if someone doesn't use them 
right? or throws an exception? in a language like D that is 
supposed to be safe?


In the case of C#, they have a construct to help with it that 
(IIRC) is something like


using(myObj)
{
} // myObj.dispose() is called when exiting this scope


For the THIRD time, I'll post my example:

class Texture { }
class Texture2D : Texture {
this() { /* load texture... */ }
~this { /* free texture */ } // OOPS, when, if ever, 
will this be called?

}

Now, does this really seem like a realistic use case to you?

using(Texture tex = new Texture2D) {
// ...
}



That no, but this yes (at least in C#):

using (LevelManager mgr = new LevelManager())
{
 //
 // Somewhere in the call stack
 Texture text = mgr.getTexture();
}
--> All level resources gone that require manual management gone
--> Ask the GC to collect the remaining memory right now

If not level wide, than maybe scene/section wide.

However I do get that not all architectures are amendable to be 
re-written in a GC friendly way.


But the approach is similar to RAII in C++, reduce new to minimum 
and allocate via factory functions that work together with handle 
manager classes.


--
Paulo

Re: D 2015/2016 Vision?

[ponce via Digitalmars-d]

On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote:


That no, but this yes (at least in C#):

using (LevelManager mgr = new LevelManager())
{
 //
 // Somewhere in the call stack
 Texture text = mgr.getTexture();
}
--> All level resources gone that require manual management gone
--> Ask the GC to collect the remaining memory right now

If not level wide, than maybe scene/section wide.

However I do get that not all architectures are amendable to be 
re-written in a GC friendly way.


But the approach is similar to RAII in C++, reduce new to 
minimum and allocate via factory functions that work together 
with handle manager classes.


--
Paulo


This is similar to Scoped!T in D. But this is not composable 
either.
You cannot have a "using()" field in a class object, much like 
you cannot have a Scoped!T field in D. In C#, you still have to 
implement IDispose interface AFAIK.

Re: DSFML reaches version 2.1

[Andrea Fontana via Digitalmars-d-announce]

On Wednesday, 7 October 2015 at 06:43:18 UTC, Jeremy DeHaan wrote:
It is my pleasure to announce that DSFML hit version 2.1! This 
version has been a long time coming, but this represents a huge 
milestone for DSFML (and for me!)


Nice job!

Re: D 2015/2016 Vision?

[Paulo Pinto via Digitalmars-d]

On Wednesday, 7 October 2015 at 07:35:05 UTC, ponce wrote:

On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote:


That no, but this yes (at least in C#):

using (LevelManager mgr = new LevelManager())
{
 //
 // Somewhere in the call stack
 Texture text = mgr.getTexture();
}
--> All level resources gone that require manual management 
gone

--> Ask the GC to collect the remaining memory right now

If not level wide, than maybe scene/section wide.

However I do get that not all architectures are amendable to 
be re-written in a GC friendly way.


But the approach is similar to RAII in C++, reduce new to 
minimum and allocate via factory functions that work together 
with handle manager classes.


--
Paulo


This is similar to Scoped!T in D. But this is not composable 
either.
You cannot have a "using()" field in a class object, much like 
you cannot have a Scoped!T field in D. In C#, you still have to 
implement IDispose interface AFAIK.


If you reduce everything to just using(), yes you are right.

However, with a bit of functional programming flavor you don't 
really need to implement  IDispose.


Just have a wrapper function own the resource.

withLevelManager (mgr => {

 //..
 Texture text = mgr.getTexture();
});

And when one is able to use languages that offer syntax sugar for 
closures as last parameter, it can be improved to


withLevelManager {

 //..
 Texture text = it.getTexture();
};


No need to implement any interface, just like a RAII handler 
implementation in C++.


Of course, this assumes all resources that were allocated via the 
level manager are going to die after the scope ends. If any 
reference to any of them is kept somewhere else, then something 
bad will happen when it gets eventually used again.


Unless I am missing something, at least in the GC languages I am 
used to, there isn't a problem with the member fields as long all 
resources that require deterministic release follow a similar 
pattern. Like with the _ptr<>() classes in C++, new should only 
exist in the deepest layers for such classes.


I guess a problem with D is the bugs that interactions between 
classes and structs still have.


--
Paulo

Re: D 2015/2016 Vision?

[Sebastiaan Koppe via Digitalmars-d]

On Wednesday, 7 October 2015 at 02:41:12 UTC, Walter Bright wrote:

On 10/6/2015 7:04 PM, bitwise wrote:
On Wednesday, 7 October 2015 at 01:27:27 UTC, Walter Bright 
wrote:

On 10/4/2015 11:02 AM, bitwise wrote:

For example, streams.


No streams. InputRanges.


This is too vague to really respond to. It does serve as an 
example of the
over-emphasis on ranges in the D community. Ranges are great, 
but not for

everything.


What can a stream do that a range cannot?


I wouldn't know about streams vs ranges, but I have worked with 
Eric Meijer's RX and observables, and it has helped a lot with 
asynchronous/evented code. Mostly because of the FP thrown in. In 
a way it is very similar to ranges and std.algorithm.


A range, however, is inherently synchronous and blocking.

If streams could be asynchronous, wouldn't that qualify?

Re: Is Anything Holding you back?

[Kagamin via Digitalmars-d]

On Tuesday, 6 October 2015 at 16:38:06 UTC, Jan Johansson wrote:
I know about that too, the KnownType is applied to types that 
the DataContractSerializer (not the XmlSerializer) must be 
aware of before it can serialize the type (you enlist the type 
to the serializer). Thanks.


For a general purpose serialization it can make sense to support 
arbitrary types, but WCF is a communication technology that 
warrants contracts including and especially web-services that 
usually require full contract to be expressed in WSDL in order to 
be cross-platform.

Re: D 2015/2016 Vision?

[Dmitry Olshansky via Digitalmars-d]

On 06-Oct-2015 23:44, ponce wrote:

On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis wrote:

Unfortunately, it is quite common to need both virtual functions and
deterministic destruction. It isn't helpful to disregard the problem by
saying "you should have used a struct", in many cases it's not any easier.



+111

--
Dmitry Olshansky

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:
Method 1: Adding a static c'tor to every module does not work 
very long in practice (as experienced first handed) cause you 
are in "cyclic c'tor hell" very quick...


The cyclic dependency checking in druntime makes static 
constructors almost unusable. It's a case of being protected so 
much while trying to do something that you can't do what you're 
trying to do. There really should be some way IMHO to have 
something similar to @trusted where you tell the compiler/runtime 
that the order does not matter for a particular static 
constructor and that it should just trust the programmer on that, 
but Walter rejected the idea when it was brought up.


- Jonathan M Davis

Re: DSFML reaches version 2.1

[Dmitry via Digitalmars-d-announce]

Thank you!

Re: Varargs and default arguments

[anonymous via Digitalmars-d-learn]

On Wednesday 07 October 2015 02:22, Steven Schveighoffer wrote:

> On 10/6/15 4:27 PM, anonymous wrote:
[...]
>> void foo(T...)(string str=null, T args = T.init) {
[...]
> I find it quite fascinating that in anonymous' solution, the T.init 
> doesn't ever actually get used!

It's not used with IFTI, but if you instantiate the template explicitly, the 
defaults arguments come up.

Or rather, they should come up. It doesn't seem to work:


void foo(T ...)(T args = T.init) {}
void main()
{
foo!(int, float)(); /* Error: foo (int _param_0, float _param_1) is not 
callable using argument types () */
}


I filed an issue: https://issues.dlang.org/show_bug.cgi?id=15170

[Issue 15027] cannot pass arguments of type DirEntry to std.file functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15027

--- Comment #14 from Walter Bright  ---
Check this out:

https://github.com/D-Programming-Language/phobos/pull/3694

--

Re: Is Anything Holding you back?

[extrawurst via Digitalmars-d]

On Monday, 5 October 2015 at 09:08:56 UTC, Jonas Drewsen wrote:

On Monday, 5 October 2015 at 06:18:45 UTC, Manu wrote:

[...]

[...]

The first method is bad because you need to mixin code manually 
for each module you have.


The second method is bad because you need to keep the 
"registration" file in sync with any modules 
added/renamed/removed.


[...]

/Jonas


Method 1: Adding a static c'tor to every module does not work 
very long in practice (as experienced first handed) cause you are 
in "cyclic c'tor hell" very quick...


--Stephan

Re: Bug? 0 is less than -10

[Andrea Fontana via Digitalmars-d-learn]

On Wednesday, 7 October 2015 at 05:27:12 UTC, Laeeth Isharc wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven 
Schveighoffer wrote:

On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your 
code ends up

being portable ;) (It's trivial to do, obviously).


ptrdiff_t

-Steve


It seems unnatural to use such a name when the variable has 
nothing to do with pointers - it doesn't contribute to the 
readability.  Yes, it's trivial, but small things cumulatively 
matter.  Adam tends to use int and when that gets mixed up with 
an auto size_t (eg via length) then his code doesn't compile on 
64 bit.  And if it happens with his code, you can imagine this 
isn't a problem that inexperienced users never encounter.


IMO it seems unnatural to use size_t with a signed/negative value 
too.

Re: Moving back to .NET

[Kagamin via Digitalmars-d]

On Wednesday, 7 October 2015 at 05:36:15 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 6 October 2015 at 17:07:27 UTC, Chris wrote:
Ok, and do you have a plan or a concrete wish list that you 
could hand over to the core developers? What features would be 
indispensable or are of utmost importance, in your opinion?


1. Define the target, then you can figure out the features.


The target is a pragmatic compiled language. Static analysis is a 
focus and believed to be done with relatively simple and clean 
language rules that ensure correct results.



2. Solid non-gc memory management and ownership.


Current direction seems to be explicit 
structs+destructors+allocators.

Re: D 2015/2016 Vision?

[rumbu via Digitalmars-d]

On Wednesday, 7 October 2015 at 07:35:05 UTC, ponce wrote:

On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote:


That no, but this yes (at least in C#):

using (LevelManager mgr = new LevelManager())
{
 //
 // Somewhere in the call stack
 Texture text = mgr.getTexture();
}
--> All level resources gone that require manual management 
gone

--> Ask the GC to collect the remaining memory right now

If not level wide, than maybe scene/section wide.

However I do get that not all architectures are amendable to 
be re-written in a GC friendly way.


But the approach is similar to RAII in C++, reduce new to 
minimum and allocate via factory functions that work together 
with handle manager classes.


--
Paulo


This is similar to Scoped!T in D. But this is not composable 
either.
You cannot have a "using()" field in a class object, much like 
you cannot have a Scoped!T field in D. In C#, you still have to 
implement IDispose interface AFAIK.


You must implement IDisposable.

using(obj = new Obj()) {
  obj.DoSomething();
}

is syntactic sugar transformed by the C# compiler in:

obj = new Obj();
try {
  obj.DoSomething();
}
finally {
  if (obj != null) (IDisposable)obj.Dispose();
}

This can be easily translated to D using a delegate instead of 
the using block, if someone is keen to use this pattern. More 
than that, due to TLS, there is no need to worry about thread 
safety in this case.


Resources are discarded in Dispose(), the class destructor is 
just calling Dispose().

Re: D and microservices

[Mengu via Digitalmars-d]

On Tuesday, 6 October 2015 at 23:01:43 UTC, Laeeth Isharc wrote:

On Tuesday, 6 October 2015 at 19:31:20 UTC, Mengu wrote:
a half of it is the buzz and other half of is not. remember 
people talking about reactjs, go and rails being buzz? they 
were the same. we have built an online payment gateway and we 
are about to decouple our application and switch to 
microservices architecture. we have an api, a dashboard, a 
checkout page, mobile flow. we have to deal with accounting 
and reporting as well. and there is no way that this 
application will turn into a giant monolith. i don't want 
that. nobody wants that. it will become something we cannot 
handle.


now a question for you.  do you wish you had built it from 
components from day one?  or do you see creating it as a blob 
to start with and then when the right divisions are clear 
factoring these out into micro-services as simply a natural 
part of the design process?  because you know much more by 
having started, and it's not so hard to refactor at this stage.


it's the latter for me. i am glad we have everything coupled 
together. this way we are able to see what parts can live by 
themselves and what parts cannot. and when you're building a 
start-up, i hardly believe designing microservices is the way to 
go. if you have time, if you have resources then go and design 
your microservices architecture. take your time, use your 
resources. but i didn't. i was one man and i did not have the 
time. now we are 4 people. we are not adding new features anymore 
and we know what kind of future is out there for our application. 
right now almost 95% of our application can be decoupled, do not 
depend on each other in terms of code. they can just communicate 
and get things done. also it means more uptime, more developers, 
more resources, etc.


we already have two microservices. one is for card vaulting and 
the other one is for end of day and cash report download/process 
service from the banks and other payment gateways. sometimes the 
industry you are in will push you that way.  and... one of the 
most important things for me with microservices is that now I can 
get Haskell and D in our codebase. :-)




another thing is whenever we do deployments we have to take 
down the whole application and go offline


pretend I'm asking you before it was deployed in production...

nobody suggests starting with microservices architecture 
because you'll never know where things will lead you however 
when it becomes a giant the suggestion is to use microservices.


some people do.  but I would have thought the point I made 
above is the real reason.  it doesn't take very long to write 
it that way from the beginning IFF you know what you want it to 
look like before you start.  and maybe you don't.  but I am 
interested in what your experience has been.


nobody, in their right minds, then. :)

Re: Moving back to .NET

[Dejan Lekic via Digitalmars-d]

Who cares? - Good luck in the .NET world.

D language implementation of DigitalOcean API

[Laeeth Isharc via Digitalmars-d]

Digital Ocean provide cloud infrastructure (KVM servers).  They 
serve a somewhat different market to Amazon's AWS and similar 
offering a much less complex product for a significantly lower 
price (especially if you pay the sticker price for Amazon).  
Unlike some other VPN providers, their servers are fast and my 
experience and that of others has been there is less contention 
for resources compared to some alternative lower-priced providers.


https://www.digitalocean.com/features/technology/
https://www.digitalocean.com/pricing/
$10/mo for 1GB RAM + 30 Gb SSD

I have ported their API v2 to D.  It's not very well-tested for 
the time being, and given the conceivable risks if your software 
should go haywire, it might not be a good idea to use in 
production just yet.  But perhaps somebody may find it useful.


Link to the code.dlang.org is here:
http://code.dlang.org/packages/digitalocean_api

DNSMadeEasy API coming up.


Laeeth.

[Issue 15176] [REG2.069b1] ICE(glue.c):separate compilation with -inline crash in glue.c

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15176

--- Comment #1 from Kenji Hara  ---
Introduced in:
https://github.com/D-Programming-Language/dmd/pull/5166

--

Re: Threading Questions

[bitwise via Digitalmars-d-learn]

On Wednesday, 7 October 2015 at 09:09:36 UTC, Kagamin wrote:

On Sunday, 4 October 2015 at 04:24:55 UTC, bitwise wrote:
I use C#(garbage collected) for making apps/games, and while, 
_in_theory_, the GC is supposed to protect you from leaks, 
memory is not the only thing that can leak. Threads need to be 
stopped, graphics resources need to be released, etc.


XNA doesn't manage graphics resources?

On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote:
I'm not sure what's going to be done with shared, but I do 
think it's annoying that you can't do this:


shared Array!int numbers;

someThread... {
numbers.clear(); // 'clear' is not shared
}

So this means that on top of the already ridiculous number of 
attributes D has, now you have to mark everything as shared 
too =/


That's illegal in other languages too except that they allow 
you to do it. If you want concurrent collections, you must code 
them separately: 
https://msdn.microsoft.com/en-us/library/system.collections.concurrent%28v=vs.110%29.aspx


I'm not sure what you mean by illegal. AFAIK 'shared' is unique 
to D. As far as simply locking and then accessing a global 
variable(class static member) in C#, there is no problem doing 
that from multiple threads.


If you have System.Collections.Generic.List(T) static class 
member, there is nothing wrong with using it from multiple 
threads like this:


class Foo {
static List numbers = new List();
void bar() {
new Thread(()=>{
lock(numbers) {
numbers.Add(1);
}).Start();
}
}

Bit

[Issue 15176] New: [REG2.069b1] ICE(glue.c):separate compilation with -inline crash in glue.c

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15176

  Issue ID: 15176
   Summary: [REG2.069b1] ICE(glue.c):separate compilation with
-inline crash in glue.c
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Keywords: ice
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

This works in 2.068.2.
But we gets an internal error(assertion) in 2.069.0-b1.

COMMAND:
dmd -c -inline test.d

test.d:
import imp;
void test() {
auto r = func();
}

imp.d:
import std.regex;
int func()
{
auto r = regex(r"a");
return 0;
}

ERROR:
Assertion failure: 'fd->semanticRun == PASSsemantic3done' on line 809 in file
'glue.c'

--

Re: Go, D, and the GC

[Shachar Shemesh via Digitalmars-d]

On 07/10/15 12:58, Timon Gehr wrote:


Shachar


struct S{
 @disable this();
 @disable enum init=0;
}

void main(){
 S s; // error
 auto d=S.init; // error
}



An honest question. Would that also cover all cases where init is being 
used implicitly by the compiler?


I will need to do some research myself, but my gut feeling is "no". 
There are several cases where the compiler replaces the value with the 
init value, and I doubt your horrid hack changes that.


Either way, I think you'll agree that D needs to be better in defining 
what is the correct path to take on this, as, currently, nobody seems to 
know for sure.


Shachar

[Issue 12558] try/catch allows implicit catching of Errors without specifying any Exception type

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12558

--- Comment #11 from Vladimir Panteleev  ---
(In reply to Vladimir Panteleev from comment #10)
> The pull request exists, Andrej filed it in the URL field:
> 
> https://github.com/D-Programming-Language/dmd/pull/3482

This pull request now has conflicts and Andrej apparently deleted his GitHub
account, so I think it can only be closed now. Is anyone interested in
resurrecting it?

--

Re: Beta D 2.069.0-b1

[Suliman via Digitalmars-d-announce]

On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


Please report any bugs at https://issues.dlang.org

-Martin


Is it DDMD based release?

Re: Beta D 2.069.0-b1

[drug via Digitalmars-d-announce]

08.10.2015 01:33, Martin Nowak пишет:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.069.0.html

Please report any bugs at https://issues.dlang.org

-Martin


Cool!

References to `cmp`, `std.experimental.allocator` reference to current 
phobos, not prerelease one. I tryied to modify the page but can't find 
info about used macros to do it.

Re: D and microservices

[Martin Nowak via Digitalmars-d]

On Wednesday, 7 October 2015 at 19:58:55 UTC, Ola Fosheim Grøstad 
wrote:
If C++17 does stackless coroutines right then it probably will 
surpass both Go and D in terms of memory locality, 
initialization performance and memory usage; and therefore 
throughput as well.


We might be able to reuse the existing delegate capture mechanism 
to create continuations.
Then await would "simply" rewrite the rest of the body as 
delegate, similar to how the foreach body can be transformed into 
a delegate.


There is some use-case for HPC code where stackless coroutines 
make a huge differences (used with a work stealing scheduler), 
for basic networking code it will only be a small difference.

Re: Categorizing Ranges

[Mike Parker via Digitalmars-d]

On Wednesday, 7 October 2015 at 15:06:55 UTC, Mike Parker wrote:


What to put into the XXX?


Thanks for the brainstorming session everyone. I'm on a deadline 
so I need to pick something and go with it. This thread has 
simplified things for me.

[Issue 12624] Internal error: backend\cgobj.c 2313 with Rebindable!(immutable TimeZone) in std.datetime

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12624

--- Comment #1 from Jonathan M Davis  ---
Still happens with the latest master, though now it spits out

Internal error: backend\cgobj.c 2332

--

Re: Beta D 2.069.0-b1

[extrawurst via Digitalmars-d-announce]

On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:

First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.069.0.html


Please report any bugs at https://issues.dlang.org

-Martin


`The -property switch has been deprecated.` Does that mean 
@property has no effect anymore ?


--Stephan

[Issue 15167] [REG2.069-devel] conflicting error with repeated alias declaration

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15167

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #4 from Kenji Hara  ---
Implemented.
https://github.com/D-Programming-Language/dmd/pull/5169

--

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Wednesday, 7 October 2015 at 13:15:11 UTC, Paulo Pinto wrote:

On Wednesday, 7 October 2015 at 12:56:32 UTC, bitwise wrote:
On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto 
wrote:

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:

[...]


That no, but this yes (at least in C#):

using (LevelManager mgr = new LevelManager())
{
 //
 // Somewhere in the call stack
 Texture text = mgr.getTexture();
}
--> All level resources gone that require manual management 
gone

--> Ask the GC to collect the remaining memory right now

If not level wide, than maybe scene/section wide.

However I do get that not all architectures are amendable to 
be re-written in a GC friendly way.


But the approach is similar to RAII in C++, reduce new to 
minimum and allocate via factory functions that work together 
with handle manager classes.


--
Paulo


Still no ;)

It's a Texture. It's meant to be seen on the screen for a 
while, not destroyed in the same scope which it was created.


In games though, we have a scene graph. When things happen, we 
often chip off a large part of it while the game is running, 
discard it, and load something new. We need to know that what 
we just discarded has been destroyed completely before we 
start loading new stuff when we're heavily constrained by 
memory. And even in cases where we aren't that constrained by 
memory, we need to know things have been destroyed, period, 
for non-memory resources. Also, when using graphics APIs like 
OpenGL, we need control over which thread an object is 
destroyed in, because you can't access OpenGL resources from 
just any thread. Now, you could set up some complicated queue 
where you send textures and so on to(latently) be destroyed, 
but this is just complicated. Picture a Hello OpenGL app in D 
and the hoops some noob would have to jump through. It's bad 
news.


Also, I should add, that a better example of the Texture thing 
would be a regular Texture and a RenderTexture. You can only 
draw to the RenderTexture, but you should be able to apply 
both to a primitive for drawing. You need polymorphism for 
this. A struct will not do.


Bit


I guess you misunderstood the // Somewhere in the call stack

It is meant as the logical region where that scene graph block 
you refer to is valid.


Anyway I was just explaining what is possible when one embraces 
the tools GC languages offer.


I still don't think your example exists in real world 
applications. Typically, you don't have that kind of control over 
the application's control-flow. You don't really have the option 
of unwinding the stack when you want to clean up. Most 
applications these days are event-based. When things are loaded 
or unloaded, it's usually as a result of some event-callback 
originating from either an input event, or a display link 
callback. To clarify, on iOS, you don't have a game loop. You can 
register a display-link or timer which will call your 'draw' or 
'update' function at a fixed interval. On top of this, you just 
can't rely on a strict hierarchical ownership of resources like 
this. large bundles of resources may be loaded/unloaded in any 
order, at any time.


And both Java and .NET do offer support such type of queues as 
well.


I was actually thinking about this.

If D had a standard runloop of some sort(like 
NSRunLoop/performSelectorOnThread: for iOS/OSX) then it would 
make queueing things to other threads a little easier. I suppose 
D's receive() API could be used to make something a little more 
specialized. But although this would allow classes to delegate 
the destruction of resources to the correct thread, it wouldn't 
resolve the problem that those destruction commands will still 
only be delegated if/when a classes destructor is actually called.


In general, I advocate any form of automatic memory/resource 
management.


+1 :)

Re: Categorizing Ranges

[Mike Parker via Digitalmars-d]

On Wednesday, 7 October 2015 at 18:26:29 UTC, qznc wrote:


Selective

Although, then stride fits better into Selective than into 
Iterative. On the other hand, iterative seems not that fitting 
to me. lockstep might also be Compositional.


I actually agree with you about iterative, but I hadn't 
considered changing it until I read this. IIRC, I picked the name 
based on the documentation. All three of the listed ranges use 
"Iterates" in the short description. I also included zip in that 
category because it's akin to lockstep, despite the intuition 
that it should be considered compositional.


Anyway, I'm not looking to establish any conventions here, just 
an easy way to describe ranges. This thread has helped a good 
deal.

Re: Go, D, and the GC

[Kapps via Digitalmars-d]

On Wednesday, 7 October 2015 at 14:50:52 UTC, Jonathan M Davis 
wrote:

On Wednesday, 7 October 2015 at 14:13:38 UTC, Meta wrote:

On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote:

struct S{
@disable this();
@disable enum init=0;
}

void main(){
S s; // error
auto d=S.init; // error
}


That's just awful.


Being able to declare a member named init is just asking for 
trouble...


https://issues.dlang.org/show_bug.cgi?id=14237
https://issues.dlang.org/show_bug.cgi?id=7066

- Jonathan M Davis


https://issues.dlang.org/show_bug.cgi?id=12233 is also related 
and incredibly bug-prone.

Tell GC to use shared memory

[tcak via Digitalmars-d-learn]

Is it possible to modify GC (without rebuilding the compiler), so 
it uses a given shared memory area instead of heap for 
allocations?

[Issue 13727] std.stdio.File not thread-safe

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13727

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #8 from Vladimir Panteleev  ---
https://github.com/DigitalMars/dmc/pull/2 (access required)

--

[Issue 15037] method TypeInfo.init shadows built-in init property

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15037

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from ag0ae...@gmail.com ---


*** This issue has been marked as a duplicate of issue 12233 ***

--

[Issue 12233] Attempting to use TypeInfo.init results in a compiler error due to lack of 'this'.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12233

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #3 from ag0ae...@gmail.com ---
*** Issue 15037 has been marked as a duplicate of this issue. ***

--

Re: Tell GC to use shared memory

[ketmar via Digitalmars-d-learn]

On Thursday, 8 October 2015 at 04:38:43 UTC, tcak wrote:
Is it possible to modify GC (without rebuilding the compiler), 
so it uses a given shared memory area instead of heap for 
allocations?


sure. you don't need to rebuild the compiler, only druntime.

Re: DSFML reaches version 2.1

[Jeremy DeHaan via Digitalmars-d-announce]

On Wednesday, 7 October 2015 at 17:13:13 UTC, Jeremy DeHaan wrote:

On Wednesday, 7 October 2015 at 16:44:30 UTC, Israel wrote:
On Wednesday, 7 October 2015 at 06:43:18 UTC, Jeremy DeHaan 
wrote:
It is my pleasure to announce that DSFML hit version 2.1! 
This version has been a long time coming, but this represents 
a huge milestone for DSFML (and for me!)


[...]


Oh and you forgot to include these in the prebuilt binaries 
for windows.


libgcc_s_dw2-1.dll
libsndfile-1.dll
libstdc++-6.dll
libwinpthread-1.dll
openal32.dll


Crap! Iknew I forgot something.  I'll get that fixed tonight. 
You should only be missing the libsndfile and openal dll's 
though. I statically linked to everything else.  Apparently 
MinGW doesn't like to do static links to these libraries?  
Maybe I'll rebuild it with VC instead.



Digging a bit, it looks like this happens in the CMake stuff. 
Basically, in normal SFML, the CMake file doesn't allow you to 
statically link to the std libs if you're building a .dll. I felt 
like with D we don't care as much about that, so I disabled the 
check. As far as I can tell it should work fine when built with 
VC(it forces /MT), but nothing special happens with MinGW so it 
still links dynamically to everything. I think I can fix it to 
work automatically, but for now I'll instead simply redo the 
packages to include those files. Thanks for catching that.

[Issue 7066] You can redefine .init and .stringof without error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7066

--- Comment #7 from Jonathan M Davis  ---
(In reply to timon.gehr from comment #6)
> (In reply to Walter Bright from comment #1)
> > They're actually supposed to be overridable at the moment. I had thought
> > there might be a use for this, but so far none have materialized.
> > ...
> 
> There is one obvious use case:
> 
> struct S{ @disable enum init=0; }
> 
> It would be better to have a specific feature here though. E.g. 
> 
> struct S{ @disable init; }

I would have thought that

struct S{ @disable this(); }

would do that in addition to making

S s;

illegal. I was surprised to find out that it didn't. But if there _is_ a good
reason for

S s = S.init;

to still work with @disable this(); was used (though I certainly can't think of
one), then @disable init; should probably imply @disable this();.

--

Re: Go, D, and the GC

[Meta via Digitalmars-d]

On Wednesday, 7 October 2015 at 18:38:34 UTC, Timon Gehr wrote:

On 10/07/2015 04:13 PM, Meta wrote:

On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote:

struct S{
@disable this();
@disable enum init=0;
}

void main(){
S s; // error
auto d=S.init; // error
}


That's just awful.


I was responding to:


Yeah, I was just expressing my disgust that D allows this.

Re: D 2015/2016 Vision?

[Marc Schütz via Digitalmars-d]

On Tuesday, 6 October 2015 at 17:03:07 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis 
wrote:

On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote:
Well, again that has it's pros and cons. This is why I just 
want a normal language solution like DIP74.


They're not the same thing at all. scoped is supposed to put 
the class on the stack, not the heap. And it's not 
ref-counted. It's so that you can create a class object in 
place, use it, and throw it away without doing any heap 
allocation. Essentially, it allows you to use a class as if it 
were a non-copyable struct. Even if we end up with 
ref-counting supported in the language, it doesn't obviate the 
need for scoped classes. They're for different use cases.


- Jonathan M Davis



On Monday, 5 October 2015 at 18:18:15 UTC, bitwise wrote:

The deterministic destruction is actually what I'm after.


For my purposes, they are pretty much the same.

So again, I'll paste the same example:

class Texture { }
class Texture2D : Texture {
this() { /* load texture... */ }
~this { /* free texture */ } // OOPS, when, if ever, 
will this be called?

}

Memory is not only thing that has to be cleaned up.

Bit


import std.stdio;
import std.typecons;

class Texture {
void bar() {
writeln("Texture.bar");
}
}

class Texture2D : Texture {
this() { writeln("this()"); }
~this() { writeln("~this()"); }
override void bar() {
writeln("Texture2D.bar");
}
}

void foo(Texture texture) {
}

void main() {
auto texture = scoped!Texture2D();
texture.bar();
foo(texture);
}


RefCounted isn't implemented for classes, but there's no reason 
why it shouldn't work.



Really, I don't get why everyone wants to have builtin 
refcounting, when all that's required is a working way to make 
escape-proof references.

Re: D and microservices

[Russel Winder via Digitalmars-d]

On Tue, 2015-10-06 at 15:07 -0400, Nick Sabalausky via Digitalmars-d
wrote:
> 
[…]
> 
> Felt stupid for not being hip to this "microservices" thing you say,
> so 
> just looked it up. But it sounds to me like it's basically just a 
> buzz-driven rediscovery of the basic principles of proper
> encapsulation 
> and Unix philosophy ("do one thing and do it well").

Yes there is an element of just using encapsulation and single purpose
tool, but there is a lot of trying to do cluster computing well by
keeping the components small and manageable. The downside is the
potential communications complexity.

BTW microservices doesn't mean just Web services/applications per se
(they are a subset), it is any protocol. The Web services/applications
people conveniently forget there are protocols other than HTTP.

> (Kinda like how "cloud" sounds like a big fancy new revolution until
> you 
> realize it's just the hip new word for "internet" or "hosted". Or 
> "Facade design pattern" vs plain old "It's a thin wrapper".)

"Cloud" is really a destruction of personal computing in favour of re-
centralization of all computing: put the computing power back in the
hands of the people who want to control what you may or may not do with
computers. Beyond this is gets political. 

> Does that sound about accurate, or am I missing something?

I think you are missing some aspects of why there is sanity to what is
happening, but you are not wrong that there is a lot of "buzz" and
"hype", but that tends to go along with anything "trendy" and "hip".
And there is a lot of reinventing the wheel because the hipsters create
cool new stuff, but have failed to study the last 60 years of computing
before doing so.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: D and microservices

[Russel Winder via Digitalmars-d]

On Wed, 2015-10-07 at 07:15 +, extrawurst via Digitalmars-d wrote:
> […]
> 
> I have never used Go, but isn't what you describe exactly what 
> vibe.d is doing using Fibers ?

As I understand it, vibe.d is a single threaded event-loop with fibres.
In this sense it is equivalent in architecture to Node except that
vibe.d allows for blocking fibres where Node required non-blocking
approaches. Thus I would choose vibe.d over Node any day, except…

Go has a task pool (goroutines), but underneath is a thread pool not a
single thread.  This means that multiple goroutines can be executing
concurrently, that means in parallel (*). GPars has an approach similar
to Go. Go is way more efficient though as it uses the kernel threads
directly, GPars has to fight with the JVM threads.


(*) It is a pity that computing and the rest of the world have
different meaning for concurrent and parallel, it leads to lots of
wonderful confusion.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Compilation error

[Loic via Digitalmars-d-learn]

On Tuesday, 15 September 2015 at 15:25:27 UTC, Loic wrote:
On Tuesday, 15 September 2015 at 12:37:46 UTC, Adam D. Ruppe 
wrote:

On Tuesday, 15 September 2015 at 09:17:26 UTC, Loic wrote:
Error: cannot find source code for runtime library file 
'object.d'


How did you install dmd? The installer exe or the zip both 
should have come with all these files packaged together.


Hello Adam,

I installed with the exe installer, and set my path to 
C:\D\dmd2\windows\bin

Maybe I forget to configure some file(s) ?

Thank you

Loic


I'am still trying to resolve my issue on Windows 7 64 bits.
No one have an idea about this error ?

Thank you

Best

Loic

Re: Go, D, and the GC

[Timon Gehr via Digitalmars-d]

On 10/05/2015 12:57 PM, Shachar Shemesh wrote:

On 05/10/15 13:39, Marc Schütz wrote:

On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote:

What's more, init is used even if you @disable this(). The following
compile and does what you'd expect (but not what you want):
struct S {
   int d;

   @disable this();
   this( int d ) {
  this.d = d;
   }
}


...

   S d = S.init;


I don't understand this. How is that not what you want, considering that
you explicitly told it to use the init value?


One of the basics of C++ is that, if you construct the type correctly,
then the user of the type cannot use it in a way that will cause
inconsistencies. Such a use will not compile.

The above shows that you cannot construct such a type in D. The language
simply does not allow you to cancel a certain feature of the type in
which you are uninterested.

Please bear in mind that the init might not be called directly.
Programmer A defines a type that should never be uninitialized (i.e. -
needs a constructor). Programmer B places an instance of that type
inside a containing struct. Programmer C uses that containing struct's
init. Such a problem is not easy to catch, even if programmers A, B and
C are the same person.

Shachar


struct S{
@disable this();
@disable enum init=0;
}

void main(){
S s; // error
auto d=S.init; // error
}

[Issue 15171] New: private/protected/package default construction

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15171

  Issue ID: 15171
   Summary: private/protected/package default construction
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

As the unit of encapsulation is the module, it sometimes makes sense to manage
construction of a certain type on a by-module basis instead of a by-type basis.

Therefore, the following code should compile:

struct S{
private this();
private init;
// (probably we also want @disable init, instead of
// needing to hack around lack of it by hiding it
// with a new declaration.)
}

Within the module, S should be default-constructible and S.init should be
accessible, but not outside the module.
This gives the author of the type full control over how S is constructed, but
it does not unduly constrain the author.

package and protected default construction are analogous. Probably, explicit
'public' should be allowed as well.

--

Re: D 2015/2016 Vision?

[Namespace via Digitalmars-d]

On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz wrote:

On Tuesday, 6 October 2015 at 17:03:07 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis 
wrote:

On Monday, 5 October 2015 at 23:08:37 UTC, bitwise wrote:
Well, again that has it's pros and cons. This is why I just 
want a normal language solution like DIP74.


They're not the same thing at all. scoped is supposed to put 
the class on the stack, not the heap. And it's not 
ref-counted. It's so that you can create a class object in 
place, use it, and throw it away without doing any heap 
allocation. Essentially, it allows you to use a class as if 
it were a non-copyable struct. Even if we end up with 
ref-counting supported in the language, it doesn't obviate 
the need for scoped classes. They're for different use cases.


- Jonathan M Davis



On Monday, 5 October 2015 at 18:18:15 UTC, bitwise wrote:

The deterministic destruction is actually what I'm after.


For my purposes, they are pretty much the same.

So again, I'll paste the same example:

class Texture { }
class Texture2D : Texture {
this() { /* load texture... */ }
~this { /* free texture */ } // OOPS, when, if ever, 
will this be called?

}

Memory is not only thing that has to be cleaned up.

Bit


import std.stdio;
import std.typecons;

class Texture {
void bar() {
writeln("Texture.bar");
}
}

class Texture2D : Texture {
this() { writeln("this()"); }
~this() { writeln("~this()"); }
override void bar() {
writeln("Texture2D.bar");
}
}

void foo(Texture texture) {
}

void main() {
auto texture = scoped!Texture2D();
texture.bar();
foo(texture);
}


RefCounted isn't implemented for classes, but there's no reason 
why it shouldn't work.



Really, I don't get why everyone wants to have builtin 
refcounting, when all that's required is a working way to make 
escape-proof references.


Because there is no guarantee that others, who use your code, get 
it right and use those constructs.

Re: Moving back to .NET

[Kagamin via Digitalmars-d]

On Wednesday, 7 October 2015 at 09:25:10 UTC, Ola Fosheim Grøstad 
wrote:
That's wonderfully undefined. A pragmatic compiled language can 
be anything from ATS to compiled Python.


If you want to know what D is in details, see dlang.org for 
language spec.


Static analysis is a focus and believed to be done with 
relatively simple and clean language rules that ensure correct 
results.


Which D is not.


If one could design a language with just four words, it would be 
lisp :)


Current direction seems to be explicit 
structs+destructors+allocators.


I don't see this. Allocators is purely a library feature and is 
not designed to be explicit either.


Buf if that is right then:

- Get rid of the dichotomy between classes and structs, having 
syntactically different pointers for classes without any 
semantic significance is rather annoying.


Semantic significance is that classes are polymorphic and hence 
reference types, structs are value types.



- Get rid of all gc-dependent language features.


@nogc


- Add language features that enables proper custom pointers.


Phobos implements custom pointers.

Re: TIOBE october

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 03:26:37 UTC, Laeeth Isharc wrote:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

d up from 31 in march.  Just below scala, sas, and fortran.  No 
doubt noisy, and possibly news about Andrei leaving Facebook 
had an influence.  They changed the algorithm to be more 
tolerant of noise, which has had an impact on the results 
(which might also be a hint about the degree of precision in 
such an exercise) but don't say how that affected D, if at all.


Really, TIOBE doesn't mean much, but it is interesting to see 
that D is _way_ above Rust (which is barely in the top 50), and 
Go didn't make the top 50 at all. I typically hear way more about 
Go and Rust from folks outside of the newsgroup than I ever hear 
about D. So, if anything, that may just show how unreliable TIOBE 
is as a real measurement of language popularity or usage, but it 
is interesting that we're that high up in comparison to the newer 
languages that we usually get compared with.


- Jonathan M Davis

Re: D and microservices

[Joakim via Digitalmars-d]

On Tuesday, 6 October 2015 at 19:07:32 UTC, Nick Sabalausky wrote:
Felt stupid for not being hip to this "microservices" thing you 
say, so just looked it up. But it sounds to me like it's 
basically just a buzz-driven rediscovery of the basic 
principles of proper encapsulation and Unix philosophy ("do one 
thing and do it well").


(Kinda like how "cloud" sounds like a big fancy new revolution 
until you realize it's just the hip new word for "internet" or 
"hosted". Or "Facade design pattern" vs plain old "It's a thin 
wrapper".)


Does that sound about accurate, or am I missing something?


Heh, funny you say that, since Russel's post just got me to look 
up the term too. :) I had encountered the term before, when I was 
talking to a dev shop about a project earlier this year, but 
figured it was exactly what it sounded like and didn't bother 
looking it up till now.  Looks like I was right.


Whatever hype may be involved, at least they're re-branding 
something _useful_, just be grateful for that. ;)


On Wednesday, 7 October 2015 at 10:39:07 UTC, Russel Winder wrote:
(Kinda like how "cloud" sounds like a big fancy new revolution 
until

you
realize it's just the hip new word for "internet" or "hosted". 
Or

"Facade design pattern" vs plain old "It's a thin wrapper".)


"Cloud" is really a destruction of personal computing in favour 
of re- centralization of all computing: put the computing power 
back in the hands of the people who want to control what you 
may or may not do with computers. Beyond this is gets political.


I wouldn't go that far.  Users want to access their data from 
anywhere on their mobile devices, and given that those mobile 
devices can't store much, the cloud is just the most convenient 
place to put the data, now that 4G speeds are comparable to wired 
broadband from just a couple years ago (except for the much lower 
quotas on wireless, which only really limit you with video).


You could have made the same argument a couple decades ago, that 
PCs were a step back from workstations, because the old UNIX 
workstations came with compilers and a toolchain that let you 
build your own software whereas you had to go get the tools for 
your PC, ie they weren't bundled.  Some people make the same 
argument with the even more locked-down tablets today, where you 
can't even develop software using them.


But the truth is that most PC users weren't developing software 
or exerting much "control" over their desktops/laptops, and 
almost nobody wants to develop software or create on a mobile 
device.  They welcome more locked-down systems, because it lets 
them do the lighter tasks they actually want to get done much 
easier, without worrying about configuring the system just right, 
ie complexity, or viruses.


However, I do agree with you that the cloud is way overplayed, 
just for different reasons.  I think decentralized computing is 
going to take off instead, with a decentralized social network, 
like Diaspora except running peer-to-peer on your mobile devices, 
replacing centralized Facebook.  Cloud will merely be one of the 
nodes in that decentralized network, one where you offload heavy 
computing activity or data that you need from everywhere else, 
but not the center of mass that many treat it as today.

Re: D 2015/2016 Vision?

[Marc Schütz via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:44:50 UTC, Jonathan M Davis 
wrote:
Having ref-counting built into the language will allow us to 
make it more efficient and provide some safety guarantees that 
can't necessarily be provided in a struct, but it doesn't make 
it so that no one can misuse ref-counted objects.


I doubt that it can gain much performance in contrast to a 
well-designed scope-like feature. In particular, elision of 
inc/dec pairs is practically free in such a system.




Ultimately, the largest benefit to having ref-counting built 
into the language will probably be that we can the have 
exceptions be reference counted [...]


Why not allow throwing structs if they subtype Throwable (via 
alias this)? This is less whacky than it sounds at first: During 
the throwing process, no postblit's don't have to be called, 
because throwing always just moves. Destruction and copying can 
only take place in catch blocks, where it's already supported. 
There would probably just be minor changes necessary to druntime 
and the compiler.

Re: Threading Questions

[Kagamin via Digitalmars-d-learn]

On Sunday, 4 October 2015 at 04:24:55 UTC, bitwise wrote:
I use C#(garbage collected) for making apps/games, and while, 
_in_theory_, the GC is supposed to protect you from leaks, 
memory is not the only thing that can leak. Threads need to be 
stopped, graphics resources need to be released, etc.


XNA doesn't manage graphics resources?

On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote:
I'm not sure what's going to be done with shared, but I do 
think it's annoying that you can't do this:


shared Array!int numbers;

someThread... {
numbers.clear(); // 'clear' is not shared
}

So this means that on top of the already ridiculous number of 
attributes D has, now you have to mark everything as shared too 
=/


That's illegal in other languages too except that they allow you 
to do it. If you want concurrent collections, you must code them 
separately: 
https://msdn.microsoft.com/en-us/library/system.collections.concurrent%28v=vs.110%29.aspx

Re: Moving back to .NET

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 7 October 2015 at 08:17:32 UTC, Kagamin wrote:

The target is a pragmatic compiled language.


That's wonderfully undefined. A pragmatic compiled language can 
be anything from ATS to compiled Python.


Static analysis is a focus and believed to be done with 
relatively simple and clean language rules that ensure correct 
results.


Which D is not.

Current direction seems to be explicit 
structs+destructors+allocators.


I don't see this. Allocators is purely a library feature and is 
not designed to be explicit either.


Buf if that is right then:

- Get rid of the dichotomy between classes and structs, having 
syntactically different pointers for classes without any semantic 
significance is rather annoying.


- Get rid of all gc-dependent language features.

- Add language features that enables proper custom pointers.

etc

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:50:35 UTC, Namespace wrote:
Language-supported ref-counting wouldn't fix that. As long as 
you're allowed to put a ref-counted object inside of a 
GC-managed object, it's possible that the GC will ultimately 
managed the lifetime of your ref-counted object - or even that 
it will never be destroyed, because it simply isn't collected 
prior to the program shutting down. And it's not like we're 
going to make it illegal to put a ref-counted object inside of 
a GC-managed object. That would be needlessly restrictive. 
Ultimately, programmers simply have to be smart about what 
they do with objects on the GC heap if deterministic 
destruction is required.


Having ref-counting built into the language will allow us to 
make it more efficient and provide some safety guarantees that 
can't necessarily be provided in a struct, but it doesn't make 
it so that no one can misuse ref-counted objects.


Ultimately, the largest benefit to having ref-counting built 
into the language will probably be that we can the have 
exceptions be reference counted - and maybe even make it so 
that they're malloced normally so that they can be used in 
@nogc code. Most of the benefits of ref-counting can already 
be done with structs.


- Jonathan M Davis


Sure, there are, of course, still ways to avoid the guarantees. 
But it's more likely that others write A a = new A("Hello"); 
instead Unique!A a = unique!A("Hello"); so we increase the 
probability that others get it right.


Well, except that then it's less obvious that an object is 
ref-counted and less likely that the programmer using it will 
realize that the object expects to have a deterministic lifetime. 
So, it might actually make the situation worse and make it so 
that programmers are more likely to get wrong. I don't think that 
it's clear at all that the situation will be better with regards 
to programmers getting it right if it's in the language. Maybe it 
will be, but maybe it won't.


- Jonathan M Davis

Re: D 2015/2016 Vision?

[Namespace via Digitalmars-d]

Well, except that then it's less obvious that an object is 
ref-counted and less likely that the programmer using it will 
realize that the object expects to have a deterministic 
lifetime. So, it might actually make the situation worse and 
make it so that programmers are more likely to get wrong. I 
don't think that it's clear at all that the situation will be 
better with regards to programmers getting it right if it's in 
the language. Maybe it will be, but maybe it won't.


- Jonathan M Davis


Well then, there is another solution: enable inheritance for 
structs as well. Then we have polymorphie and deterministic 
lifetimes. Of course we cannot expect too much magic. But an 
example:



struct A {
int hello() {
return 42;
}
}

struct B : A {
override int hello() {
return 23;
}
}

void foo(A* a) {
writeln(a.hello()); // prints 23
}

void main() {
A* b = new B();
foo(b);
}


That shouldn't be too complex, since it follows the rules of C++: 
http://cpp.sh/9r6k

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:03:44 UTC, Namespace wrote:

On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz wrote:
Really, I don't get why everyone wants to have builtin 
refcounting, when all that's required is a working way to make 
escape-proof references.


Because there is no guarantee that others, who use your code, 
get it right and use those constructs.


Language-supported ref-counting wouldn't fix that. As long as 
you're allowed to put a ref-counted object inside of a GC-managed 
object, it's possible that the GC will ultimately managed the 
lifetime of your ref-counted object - or even that it will never 
be destroyed, because it simply isn't collected prior to the 
program shutting down. And it's not like we're going to make it 
illegal to put a ref-counted object inside of a GC-managed 
object. That would be needlessly restrictive. Ultimately, 
programmers simply have to be smart about what they do with 
objects on the GC heap if deterministic destruction is required.


Having ref-counting built into the language will allow us to make 
it more efficient and provide some safety guarantees that can't 
necessarily be provided in a struct, but it doesn't make it so 
that no one can misuse ref-counted objects.


Ultimately, the largest benefit to having ref-counting built into 
the language will probably be that we can the have exceptions be 
reference counted - and maybe even make it so that they're 
malloced normally so that they can be used in @nogc code. Most of 
the benefits of ref-counting can already be done with structs.


- Jonathan M Davis

Re: D and microservices

[Dicebot via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:50:47 UTC, Russel Winder wrote:
What do you mean by microservice examples? It is 
infrastructure methodology, not specific code thing, any 
simple network service can be viewed as microservice.


At the Web services application level it is having a small 
framework for structuring the use of GET, POST, PUT, DELETE,… 
packets. Basically RESTful services.


Even web microservices are not necessarily RESTful ones. Nick has 
correctly pointed out that there is a lot of spiritual similariy 
between concept of microservice and traditional UNIX way of 
designing small single-purpose command lines apps. It basically 
gets down to "do as few things as possible in one application 
(but do it good) and build a pipeline".


At a non HTTP level I guess you can say all networking is 
microservices except that you want a protocol over TCP/IP or 
UDP/IP and shouldn't there be frameworks to assist building 
these things?


What utility would you expect from such framework?

Re: D 2015/2016 Vision?

[Marc Schütz via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:03:44 UTC, Namespace wrote:
Because there is no guarantee that others, who use your code, 
get it right and use those constructs.


The obvious way would be to make the constructor private and only 
provide a factory method returning a Scoped!Texture2D. I just 
tried that, but ran into problems with the construction (probably 
a bug in emplace). Don't have time to investigate this now. Maybe 
you can also return a Unique!Texture2D, but that one doesn't have 
an alias this...

[Issue 15149] [REG2.068.1] Linker error with separate compilation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15149

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/1f59030b3af81efe67139ecb0c7d3f6e2312d5a7
fix Issue 15149 - Linker error with separate compilation

https://github.com/D-Programming-Language/dmd/commit/95d076460c87a252edbbcc8d995061391738bd51
Merge pull request #5166 from 9rnsr/fix15149

[REG2.068.1] Issue 15149 - Linker error with separate compilation

--

[Issue 15149] [REG2.068.1] Linker error with separate compilation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15149

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Is Anything Holding you back?

[Johannes Pfau via Digitalmars-d]

Am Wed, 07 Oct 2015 08:41:30 +
schrieb Jonathan M Davis :

> On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:
> > Method 1: Adding a static c'tor to every module does not work 
> > very long in practice (as experienced first handed) cause you 
> > are in "cyclic c'tor hell" very quick...
> 
> The cyclic dependency checking in druntime makes static 
> constructors almost unusable. It's a case of being protected so 
> much while trying to do something that you can't do what you're 
> trying to do. There really should be some way IMHO to have 
> something similar to @trusted where you tell the compiler/runtime 
> that the order does not matter for a particular static 
> constructor and that it should just trust the programmer on that, 
> but Walter rejected the idea when it was brought up.
> 
> - Jonathan M Davis

With LDC you can abuse the C constructor mechanism to do that. GDC does
not yet expose C constructors to D code but it's on my list and it's
easy to implement.

Re: D and microservices

[Russel Winder via Digitalmars-d]

On Tue, 2015-10-06 at 18:56 +, Dicebot via Digitalmars-d wrote:
> On Tuesday, 6 October 2015 at 16:12:12 UTC, Russel Winder wrote:
> > Has anyone got a small example of microservices using D, with 
> > Vibe.d or otherwise, that I can make use of? I need some 
> > examples of small microservices for a session at μCon 2015.
> 
> What do you mean by microservice examples? It is infrastructure 
> methodology, not specific code thing, any simple network service 
> can be viewed as microservice.

At the Web services application level it is having a small framework
for structuring the use of GET, POST, PUT, DELETE,… packets. Basically
RESTful services.

At a non HTTP level I guess you can say all networking is microservices
except that you want a protocol over TCP/IP or UDP/IP and shouldn't
there be frameworks to assist building these things?

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: D 2015/2016 Vision?

[Namespace via Digitalmars-d]

Language-supported ref-counting wouldn't fix that. As long as 
you're allowed to put a ref-counted object inside of a 
GC-managed object, it's possible that the GC will ultimately 
managed the lifetime of your ref-counted object - or even that 
it will never be destroyed, because it simply isn't collected 
prior to the program shutting down. And it's not like we're 
going to make it illegal to put a ref-counted object inside of 
a GC-managed object. That would be needlessly restrictive. 
Ultimately, programmers simply have to be smart about what they 
do with objects on the GC heap if deterministic destruction is 
required.


Having ref-counting built into the language will allow us to 
make it more efficient and provide some safety guarantees that 
can't necessarily be provided in a struct, but it doesn't make 
it so that no one can misuse ref-counted objects.


Ultimately, the largest benefit to having ref-counting built 
into the language will probably be that we can the have 
exceptions be reference counted - and maybe even make it so 
that they're malloced normally so that they can be used in 
@nogc code. Most of the benefits of ref-counting can already be 
done with structs.


- Jonathan M Davis


Sure, there are, of course, still ways to avoid the guarantees. 
But it's more likely that others write A a = new A("Hello"); 
instead Unique!A a = unique!A("Hello"); so we increase the 
probability that others get it right.

Re: Is Anything Holding you back?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:03:11 UTC, Johannes Pfau wrote:

Am Wed, 07 Oct 2015 08:41:30 +
schrieb Jonathan M Davis :


On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:
> Method 1: Adding a static c'tor to every module does not 
> work very long in practice (as experienced first handed) 
> cause you are in "cyclic c'tor hell" very quick...


The cyclic dependency checking in druntime makes static 
constructors almost unusable. It's a case of being protected 
so much while trying to do something that you can't do what 
you're trying to do. There really should be some way IMHO to 
have something similar to @trusted where you tell the 
compiler/runtime that the order does not matter for a 
particular static constructor and that it should just trust 
the programmer on that, but Walter rejected the idea when it 
was brought up.


- Jonathan M Davis


With LDC you can abuse the C constructor mechanism to do that. 
GDC does not yet expose C constructors to D code but it's on my 
list and it's easy to implement.


I'm not quite sure what you mean by C constructors, so I don't 
know how that works, but unless it's in all of the compilers, I 
don't think that it's really worth much ultimately. And we _do_ 
have workarounds already. std.stdio is an example of one such 
module where what is essentially its static constructor is called 
by another module in order to break the cycle. But then you lose 
out on the special benefits of static constructors with regards 
to initializing stuff like immutable objects, which can be a 
problem - particularly when stuff like pure gets involved.


Honestly, I think that if we don't want it to be considered 
borderline bad practice to use static constructors, I think that 
we need a solution for this that allows them to function normally 
without being concerned about circular dependencies (at least 
when the programmer marks them as such). And if the C constructor 
mechanism that you're talking about somehow does that, then 
great, but it needs to be standard D, or it's a pretty limited 
solution.


- Jonathan M Davis

Re: D 2015/2016 Vision?

[Namespace via Digitalmars-d]

On Wednesday, 7 October 2015 at 11:27:49 UTC, Marc Schütz wrote:

On Wednesday, 7 October 2015 at 10:03:44 UTC, Namespace wrote:
Because there is no guarantee that others, who use your code, 
get it right and use those constructs.


The obvious way would be to make the constructor private and 
only provide a factory method returning a Scoped!Texture2D. I 
just tried that, but ran into problems with the construction 
(probably a bug in emplace). Don't have time to investigate 
this now. Maybe you can also return a Unique!Texture2D, but 
that one doesn't have an alias this...


Something like this?


import std.stdio;

struct Scoped(T) if (is(T == class)) {
private void[__traits(classInstanceSize, T)] _buf = void;

this(Args...)(auto ref Args args) {
_buf = typeid(T).init[];
this.get().__ctor(args);
}

@disable
this(this);

~this() {
.destroy(this.get());
}

@nogc
private inout(T) get() inout pure nothrow {
return cast(T) _buf.ptr;
}

auto opDispatch(string method, Args...)(auto ref Args args) {
return mixin("this.get()." ~ method ~ "(args)");
}
}

class A {
private string name;

private this(string name) {
   this.name = name;
   writeln("Creating A");
}

static auto scoped(Args...)(auto ref Args args) {
return Scoped!(typeof(this))(args);
}

~this() {
   writeln("Destroying A");
}

void hello() {
   writeln("Hello, ", this.name);
}
}

void main() {
auto a = A.scoped("Foo");
a.hello();
}


Kinda ugly, but it works.

Re: DSFML reaches version 2.1

[suliman via Digitalmars-d-announce]

Perfect!!! Big thanks! I think not only one are tired from GTK, 
and need simple and compact gui lib

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Wednesday, 7 October 2015 at 05:13:06 UTC, Walter Bright wrote:

On 10/6/2015 7:57 PM, bitwise wrote:
Again though, if I have to restate what I've been arguing for 
as simply as
possible, it's that I want to use RAII and polymorphism at the 
same time, as a
natural language solution. DIP74 would satisfy everything I'm 
asking for.


Yes. We need to do that.


I think that every nanometer this one gets moved up the todo list 
will be a big win.


Bit

Re: DSFML reaches version 2.1

[Erika Quinn via Digitalmars-d-announce]

It's great to see all this work finally come to fruition, 
congrats Jebbs!


(DSFML is totally worth checking out; I've been using it in my 
project for a couple years now)

Re: D 2015/2016 Vision?

[Paulo Pinto via Digitalmars-d]

On Wednesday, 7 October 2015 at 12:56:32 UTC, bitwise wrote:

On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote:

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:

[...]


That no, but this yes (at least in C#):

using (LevelManager mgr = new LevelManager())
{
 //
 // Somewhere in the call stack
 Texture text = mgr.getTexture();
}
--> All level resources gone that require manual management 
gone

--> Ask the GC to collect the remaining memory right now

If not level wide, than maybe scene/section wide.

However I do get that not all architectures are amendable to 
be re-written in a GC friendly way.


But the approach is similar to RAII in C++, reduce new to 
minimum and allocate via factory functions that work together 
with handle manager classes.


--
Paulo


Still no ;)

It's a Texture. It's meant to be seen on the screen for a 
while, not destroyed in the same scope which it was created.


In games though, we have a scene graph. When things happen, we 
often chip off a large part of it while the game is running, 
discard it, and load something new. We need to know that what 
we just discarded has been destroyed completely before we start 
loading new stuff when we're heavily constrained by memory. And 
even in cases where we aren't that constrained by memory, we 
need to know things have been destroyed, period, for non-memory 
resources. Also, when using graphics APIs like OpenGL, we need 
control over which thread an object is destroyed in, because 
you can't access OpenGL resources from just any thread. Now, 
you could set up some complicated queue where you send textures 
and so on to(latently) be destroyed, but this is just 
complicated. Picture a Hello OpenGL app in D and the hoops some 
noob would have to jump through. It's bad news.


Also, I should add, that a better example of the Texture thing 
would be a regular Texture and a RenderTexture. You can only 
draw to the RenderTexture, but you should be able to apply both 
to a primitive for drawing. You need polymorphism for this. A 
struct will not do.


Bit


I guess you misunderstood the // Somewhere in the call stack

It is meant as the logical region where that scene graph block 
you refer to is valid.


As for OpenGL being complex, fear not, Vulkan, Metal and DX 12 
are here to help (ca 600 LOC for a triangle). :)


And both Java and .NET do offer support such type of queues as 
well.


Anyway I was just explaining what is possible when one embraces 
the tools GC languages offer.


In general, I advocate any form of automatic memory/resource 
management. With substructural type systems now being my 
favorite, but they still have an uphill battle for adoption.


Also as a note, Microsoft will be discussing their proposed C++ 
solution with the Rust team.


--
Paulo

Re: Moving back to .NET

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:18:16 UTC, Kagamin wrote:
If you want to know what D is in details, see dlang.org for 
language spec.


No, that is backwards. :-) The language spec is the product. What 
is needed is a definition of what the problem area is (e.g. use 
cases).


problem area -> design -> language spec

If one could design a language with just four words, it would 
be lisp :)


That is actually pretty close. The more powerful semantic 
analysis engines are based on horn clauses.


(you translate the imperative constructs into horn clauses, then 
do analysis)


Semantic significance is that classes are polymorphic and hence 
reference types, structs are value types.


Not real difference regarding pointers.


- Get rid of all gc-dependent language features.


@nogc


No, remove them from the language and replace them with library 
friendly constructs.



- Add language features that enables proper custom pointers.


Phobos implements custom pointers.


They are not sound, and that is a language issue, not a library 
issue.

[Issue 15174] New: Add or undocument --tmpdir switch

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15174

  Issue ID: 15174
   Summary: Add or undocument --tmpdir switch
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

The rdmd man page mentions a --tmpdir switch, however it is not actually
recognized by rdmd.

--

[Issue 15175] New: rdmd --loop and --eval now complain about std.stream deprecation warnings

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15175

  Issue ID: 15175
   Summary: rdmd --loop and --eval now complain about std.stream
deprecation warnings
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

> rdmd --force "--eval=writeln(`eval_works`);"
C:\Temp\.rdmd\eval.B69BD6FDCFC0950D6C336FE7B8FEF8B5.d(6): Deprecation: module
std.cstream is deprecated - It will be removed from Phobos in October 2016. If
you still need it, go to https://github.com/DigitalMars/undeaD
C:\D2\src\phobos\std\cstream.d(27): Deprecation: module std.stream is
deprecated - It will be removed from Phobos in October 2016. If you still need
it, go to https://github.com/DigitalMars/undeaD
C:\Temp\.rdmd\eval.B69BD6FDCFC0950D6C336FE7B8FEF8B5.d(13): Deprecation: module
std.socketstream is deprecated - It will be removed from Phobos in October
2016. If you still need it, go to https://github.com/DigitalMars/undeaD
C:\D2\src\phobos\std\socketstream.d(41): Deprecation: module std.stream is
deprecated - It will be removed from Phobos in October 2016. If you still need
it, go to https://github.com/DigitalMars/undeaD
C:\Temp\.rdmd\eval.B69BD6FDCFC0950D6C336FE7B8FEF8B5.d(13): Deprecation: module
std.stream is deprecated - It will be removed from Phobos in October 2016. If
you still need it, go to https://github.com/DigitalMars/undeaD
C:\Temp\.rdmd\eval.B69BD6FDCFC0950D6C336FE7B8FEF8B5.d(6): Deprecation: module
std.cstream is deprecated - It will be removed from Phobos in October 2016. If
you still need it, go to https://github.com/DigitalMars/undeaD
C:\D2\src\phobos\std\cstream.d(27): Deprecation: module std.stream is
deprecated - It will be removed from Phobos in October 2016. If you still need
it, go to https://github.com/DigitalMars/undeaD
C:\Temp\.rdmd\eval.B69BD6FDCFC0950D6C336FE7B8FEF8B5.d(13): Deprecation: module
std.socketstream is deprecated - It will be removed from Phobos in October
2016. If you still need it, go to https://github.com/DigitalMars/undeaD
C:\D2\src\phobos\std\socketstream.d(41): Deprecation: module std.stream is
deprecated - It will be removed from Phobos in October 2016. If you still need
it, go to https://github.com/DigitalMars/undeaD
C:\Temp\.rdmd\eval.B69BD6FDCFC0950D6C336FE7B8FEF8B5.d(13): Deprecation: module
std.stream is deprecated - It will be removed from Phobos in October 2016. If
you still need it, go to https://github.com/DigitalMars/undeaD
eval_works

--

Re: DSFML reaches version 2.1

[Jeremy DeHaan via Digitalmars-d-announce]

On Wednesday, 7 October 2015 at 12:44:13 UTC, suliman wrote:
Perfect!!! Big thanks! I think not only one are tired from GTK, 
and need simple and compact gui lib


It's not really a gui library. I mean, you could use it as such I 
guess, but it's more for game development.

Re: Compilation error

[Loic via Digitalmars-d-learn]

On Wednesday, 7 October 2015 at 12:08:08 UTC, Loic wrote:

On Tuesday, 15 September 2015 at 15:25:27 UTC, Loic wrote:
On Tuesday, 15 September 2015 at 12:37:46 UTC, Adam D. Ruppe 
wrote:

On Tuesday, 15 September 2015 at 09:17:26 UTC, Loic wrote:
Error: cannot find source code for runtime library file 
'object.d'


How did you install dmd? The installer exe or the zip both 
should have come with all these files packaged together.


Hello Adam,

I installed with the exe installer, and set my path to 
C:\D\dmd2\windows\bin

Maybe I forget to configure some file(s) ?

Thank you

Loic


I'am still trying to resolve my issue on Windows 7 64 bits.
No one have an idea about this error ?

Thank you

Best

Loic


Finally, I found the solution, by just changed the entry of 
"Environment" in sc.ini.


sorry

Thank you

Loic

[Issue 15162] byDchar calls empty twice in a row

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15162

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #1 from John Colvin  ---
Not totally sure, but I think you're just seeing
https://github.com/D-Programming-Language/phobos/blob/master/std/utf.d#L1169

--

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz wrote:
RefCounted isn't implemented for classes, but there's no reason 
why it shouldn't work.



Really, I don't get why everyone wants to have builtin 
refcounting, when all that's required is a working way to make 
escape-proof references.


If you make a class that owns a resources that needs 
deterministic destruction, there is no guarantee that everyone 
will wrap that class in a RefCounted properly. Also, I've already 
stated many more problems with struct wrappers.

Re: TIOBE october

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:55:21 UTC, Jonathan M Davis 
wrote:
On Wednesday, 7 October 2015 at 03:26:37 UTC, Laeeth Isharc 
wrote:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

d up from 31 in march.  Just below scala, sas, and fortran.  
No doubt noisy, and possibly news about Andrei leaving 
Facebook had an influence.  They changed the algorithm to be 
more tolerant of noise, which has had an impact on the results 
(which might also be a hint about the degree of precision in 
such an exercise) but don't say how that affected D, if at all.


Really, TIOBE doesn't mean much, but it is interesting to see 
that D is _way_ above Rust (which is barely in the top 50), and 
Go didn't make the top 50 at all. I typically hear way more 
about Go and Rust from folks outside of the newsgroup than I 
ever hear about D. So, if anything, that may just show how 
unreliable TIOBE is as a real measurement of language 
popularity or usage, but it is interesting that we're that high 
up in comparison to the newer languages that we usually get 
compared with.


- Jonathan M Davis


Yes.  TIOBE probably wrong about popularity, and although it is 
in our favour, it's probably a mistake to point to TIOBE, and 
indeed nobody here does.

Re: Bug? 0 is less than -10

[Laeeth Isharc via Digitalmars-d-learn]

On Wednesday, 7 October 2015 at 07:38:44 UTC, Andrea Fontana 
wrote:
On Wednesday, 7 October 2015 at 05:27:12 UTC, Laeeth Isharc 
wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven 
Schveighoffer wrote:

On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your 
code ends up

being portable ;) (It's trivial to do, obviously).


ptrdiff_t

-Steve


It seems unnatural to use such a name when the variable has 
nothing to do with pointers - it doesn't contribute to the 
readability.  Yes, it's trivial, but small things cumulatively 
matter.  Adam tends to use int and when that gets mixed up 
with an auto size_t (eg via length) then his code doesn't 
compile on 64 bit.  And if it happens with his code, you can 
imagine this isn't a problem that inexperienced users never 
encounter.


IMO it seems unnatural to use size_t with a signed/negative 
value too.
Indeed.  But you end up with an inferred size_t in a foreach and 
using length with auto, so it makes sense to have something nicer 
that you can specify that won't make your code look strange.  
Doesn't bother me since I define ssize_t, but it might make D 
easier to read for others.  When you see ptrdiff_t with no 
pointer in sight it's not very clear unless you are familiar with 
C idioms (and I never remember seeing this back when I learnt C - 
some modern thing).

Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Wednesday, 7 October 2015 at 07:24:03 UTC, Paulo Pinto wrote:

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 18:43:42 UTC, Jonathan M Davis 
wrote:

On Tuesday, 6 October 2015 at 18:10:42 UTC, bitwise wrote:
On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis 
wrote:
I'm not sure what else I can say. The example I posted says 
it all, and it can't be done properly in D (or C#, but why 
lower the bar because of their mistakes? ;)


It's a side effect of having the lifetime of an object 
managed by the GC. There's no way around that except to use 
something else like manual memory management or reference 
counting.


You are literally repeating what I just said in different 
words.


in D, it's a good reason to use structs to manage resources 
like that, and since most objects really have no need of 
inheritance and have no business being classes, it's usually 
fine.


This is an opinion.

I want polymorphism AND deterministic destruction, and the 
least you could do is just admit that it's a downside to D not 
having it, instead of trying to tell me that everything I know 
is wrong..


But in the cases where you do have to use a class, it can get 
annoying.


YES, its does, and it's not just an odd case here and there..

You simply do not rely on the GC or the destruction of the 
object to free system resources. You manually call a function 
on the object to free those resources when you're done with 
it.


I'm sorry, but I almost can't believe you're saying this.

So, you're saying you want me to just revert back to manual 
resource management and accept that huge resources like 
textures and such may just leak if someone doesn't use them 
right? or throws an exception? in a language like D that is 
supposed to be safe?


In the case of C#, they have a construct to help with it that 
(IIRC) is something like


using(myObj)
{
} // myObj.dispose() is called when exiting this scope


For the THIRD time, I'll post my example:

class Texture { }
class Texture2D : Texture {
this() { /* load texture... */ }
~this { /* free texture */ } // OOPS, when, if ever, 
will this be called?

}

Now, does this really seem like a realistic use case to you?

using(Texture tex = new Texture2D) {
// ...
}



That no, but this yes (at least in C#):

using (LevelManager mgr = new LevelManager())
{
 //
 // Somewhere in the call stack
 Texture text = mgr.getTexture();
}
--> All level resources gone that require manual management gone
--> Ask the GC to collect the remaining memory right now

If not level wide, than maybe scene/section wide.

However I do get that not all architectures are amendable to be 
re-written in a GC friendly way.


But the approach is similar to RAII in C++, reduce new to 
minimum and allocate via factory functions that work together 
with handle manager classes.


--
Paulo


Still no ;)

It's a Texture. It's meant to be seen on the screen for a while, 
not destroyed in the same scope which it was created.


In games though, we have a scene graph. When things happen, we 
often chip off a large part of it while the game is running, 
discard it, and load something new. We need to know that what we 
just discarded has been destroyed completely before we start 
loading new stuff when we're heavily constrained by memory. And 
even in cases where we aren't that constrained by memory, we need 
to know things have been destroyed, period, for non-memory 
resources. Also, when using graphics APIs like OpenGL, we need 
control over which thread an object is destroyed in, because you 
can't access OpenGL resources from just any thread. Now, you 
could set up some complicated queue where you send textures and 
so on to(latently) be destroyed, but this is just complicated. 
Picture a Hello OpenGL app in D and the hoops some noob would 
have to jump through. It's bad news.


Also, I should add, that a better example of the Texture thing 
would be a regular Texture and a RenderTexture. You can only draw 
to the RenderTexture, but you should be able to apply both to a 
primitive for drawing. You need polymorphism for this. A struct 
will not do.


Bit

Categorizing Ranges

[Mike Parker via Digitalmars-d]

I'm looking for ideas on how to label the ranges returned from 
take and drop. Some examples of what I think are appropriate 
categories for other types of ranges:


Generative - iota, recurrence, sequence
Compositional - chain, roundRobin, transposed
Iterative - retro, stride, lockstep
XXX - take, drop

What to put into the XXX? I first thought of "Greedy", but that 
has an association with "greedy algorithms" that I don't really 
like. That led to "Selfish", but it's admittedly not that 
appropriate. Beyond that, I'm stuck. Any and all ideas 
appreciated.

Re: Categorizing Ranges

[Big Daddy via Digitalmars-d]

On Wednesday, 7 October 2015 at 15:06:55 UTC, Mike Parker wrote:
I'm looking for ideas on how to label the ranges returned from 
take and drop. Some examples of what I think are appropriate 
categories for other types of ranges:


Generative - iota, recurrence, sequence
Compositional - chain, roundRobin, transposed
Iterative - retro, stride, lockstep
XXX - take, drop

What to put into the XXX? I first thought of "Greedy", but that 
has an association with "greedy algorithms" that I don't really 
like. That led to "Selfish", but it's admittedly not that 
appropriate. Beyond that, I'm stuck. Any and all ideas 
appreciated.


eager

Re: Go, D, and the GC

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 14:13:38 UTC, Meta wrote:

On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote:

struct S{
@disable this();
@disable enum init=0;
}

void main(){
S s; // error
auto d=S.init; // error
}


That's just awful.


Being able to declare a member named init is just asking for 
trouble...


https://issues.dlang.org/show_bug.cgi?id=14237
https://issues.dlang.org/show_bug.cgi?id=7066

- Jonathan M Davis

Re: Go, D, and the GC

[Meta via Digitalmars-d]

On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote:

struct S{
@disable this();
@disable enum init=0;
}

void main(){
S s; // error
auto d=S.init; // error
}


That's just awful.

Re: Is Anything Holding you back?

[Johannes Pfau via Digitalmars-d]

Am Wed, 07 Oct 2015 10:50:38 +
schrieb Jonathan M Davis :

> On Wednesday, 7 October 2015 at 10:03:11 UTC, Johannes Pfau wrote:
> > Am Wed, 07 Oct 2015 08:41:30 +
> > schrieb Jonathan M Davis :
> >
> >> On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:
> >> > Method 1: Adding a static c'tor to every module does not 
> >> > work very long in practice (as experienced first handed) 
> >> > cause you are in "cyclic c'tor hell" very quick...
> >> 
> >> The cyclic dependency checking in druntime makes static 
> >> constructors almost unusable. It's a case of being protected 
> >> so much while trying to do something that you can't do what 
> >> you're trying to do. There really should be some way IMHO to 
> >> have something similar to @trusted where you tell the 
> >> compiler/runtime that the order does not matter for a 
> >> particular static constructor and that it should just trust 
> >> the programmer on that, but Walter rejected the idea when it 
> >> was brought up.
> >> 
> >> - Jonathan M Davis
> >
> > With LDC you can abuse the C constructor mechanism to do that. 
> > GDC does not yet expose C constructors to D code but it's on my 
> > list and it's easy to implement.
> 
> I'm not quite sure what you mean by C constructors, so I don't 
> know how that works, but unless it's in all of the compilers, I 
> don't think that it's really worth much ultimately. 

Most C compilers support some __attribute(constructor)__ feature.
In LDC this translates to something like this:

import ldc.attribute;

@attribute("constructor") extern(C) void myConstructor()
{
}

and GDC will use basically the same syntax. It's not really meant for
end users though. We can use this to implement some parts of
the druntime shared DSO handling. And it's useful for betterC programs
or embedded systems, as the implementation in the (C) runtime is very
simple. But you're right, this is probably not a good / general purpose
solution. It just wanted to point out that there's another possible
workaround ;-)

> And we _do_ 
> have workarounds already. std.stdio is an example of one such 
> module where what is essentially its static constructor is called 
> by another module in order to break the cycle. But then you lose 
> out on the special benefits of static constructors with regards 
> to initializing stuff like immutable objects, which can be a 
> problem - particularly when stuff like pure gets involved.
> 
> Honestly, I think that if we don't want it to be considered 
> borderline bad practice to use static constructors, I think that 
> we need a solution for this that allows them to function normally 
> without being concerned about circular dependencies (at least 
> when the programmer marks them as such).

I think it wouldn't be hard to implement a solution. I guess it's
mainly a political discussion :-(

An UDA which can be placed on functions with certain signatures would
be nice. And this allows having multiple static ctors per module
(Could be useful for constructors in mixins):

@constructor void myConstructor() //compiler enforces function signature
{
}

> And if the C constructor 
> mechanism that you're talking about somehow does that, then 
> great, but it needs to be standard D, or it's a pretty limited 
> solution.

If we can have a standard solution in DMD there are better ways than
relying on C constructors. The druntime has absolutely no control over
'C constructors' (they're called by the C runtime) which can lead to
problems in some corner cases. C constructors are mainly useful for low
level or embedded code. And they're useful as long as we don't have a
standard solution, as GDC/LDC can implement them without DMDs
approval ;-)

Re: D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 11:21:04 UTC, Namespace wrote:
Well, except that then it's less obvious that an object is 
ref-counted and less likely that the programmer using it will 
realize that the object expects to have a deterministic 
lifetime. So, it might actually make the situation worse and 
make it so that programmers are more likely to get wrong. I 
don't think that it's clear at all that the situation will be 
better with regards to programmers getting it right if it's in 
the language. Maybe it will be, but maybe it won't.


- Jonathan M Davis


Well then, there is another solution: enable inheritance for 
structs as well. Then we have polymorphie and deterministic 
lifetimes. Of course we cannot expect too much magic. But an 
example:


How does that solve anything? The problem is that some types need 
a deterministic lifetime, and no object whose lifetime is managed 
by the GC gets a deterministic lifetime. So, even if an object 
supports deterministic destruction, that stops working as soon as 
its put inside of something whose lifetime is managed by the GC. 
Whether the object with deterministic destruction has inheritance 
or not doesn't really matter, and whether it naturally has 
deterministic destruction or whether it has it because it's being 
used in smart pointer doesn't really matter. It's the fact that 
it was put in an object whose lifetime is managed by the GC that 
screws with things.


Even if D classes were identical to C++ classes, and we had no 
structs, the fact that we have a GC managing the lifetime of 
anything causes problems with any type that needs deterministic 
destruction.


What's needed is to have a smart pointer of some kind to manage 
the lifetime of objects on the heap that need deterministic 
destruction and then to have the programmer make sure that they 
do put any of such objects inside of an object whose lifetime is 
managed by the GC if they want the deterministic destruction to 
work. You can't get away from requiring the programmer to be 
smart about things here unless you simply have no GC (which then 
requires them to smart about other things), or any type with 
deterministic destruction simply isn't allowed to be on the GC 
heap, which is unnecessarily limiting, particularly since in many 
cases, it's perfectly okay to let objects that might normally be 
destroy deterministically to be destroyed at the GC's leisure.


std.typecons.RefCounted aside, it's quite possible as-is to 
implement smart pointers in D with structs, thus providing 
deterministic destruction for reference types. I don't know why 
RefCounted wasn't implemented to work with classes, and I don't 
know why Walter and Andrei think that something like DIP 74 is 
necessary to support ref-counting. I might have heard, but if so, 
I forgot. It probably comes down to a loophole somewhere in how 
structs are put together that makes it throw off the ref-count 
(maybe something to do with init values), but that's speculation 
on my part. Regardless, if we have a proper ref-counting 
mechanism for classes (built-in or not doesn't necessarily matter 
- it just needs to work), then the folks that need deterministic 
destruction with polymorphism get it. But they're always going to 
have be careful about having such objects on the GC heap due to 
the nature of garbage collection.


- Jonathan M Davis

Re: Shout out to D at cppcon, when talkign about ranges.

[Trass3r via Digitalmars-d]

On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler wrote:
Yes, this is an explanation. Thanks. So the argument being C++ 
customs. Now that you mention it, this seems to be the argument 
in Eric's D4128 paper, too.


I was hoping for a somewhat deeper reasoning. Out of curiously, 
I am still trying to grasp all the implications. Ranges are 
hard.


Another one is "odd number of iterators algorithms"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity
D’s choice of algorithmic basis operations is inherently less 
efficient than C++’s.

Re: Shout out to D at cppcon, when talkign about ranges.

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 16:33:21 UTC, John Colvin wrote:

On Wednesday, 7 October 2015 at 14:59:28 UTC, Trass3r wrote:
On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler 
wrote:
Yes, this is an explanation. Thanks. So the argument being 
C++ customs. Now that you mention it, this seems to be the 
argument in Eric's D4128 paper, too.


I was hoping for a somewhat deeper reasoning. Out of 
curiously, I am still trying to grasp all the implications. 
Ranges are hard.


Another one is "odd number of iterators algorithms"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity
D’s choice of algorithmic basis operations is inherently less 
efficient than C++’s.


Hmm. That seems really contrived and/or missing the point. You 
would never design a function like that for use with ranges, 
but that doesn't mean you're any less able to efficiently find 
word boundaries using ranges.


As I understand it, there are algorithms that inherently need 3 
iterators to do whatever is they do, and the question of how to 
deal with them has come up before in the newsgroup. I think that 
it's pretty clear that such algorithms are relatively few in 
number, but they do exist, and solving them with ranges does get 
potentially awkward. Similarly, using iterators with containers 
when you have to pass them to the container generally works 
better than ranges do. We've had to add overloads to  the 
std.container types which take the results of the various take 
functions in order to work around that problem. So, there are 
clearly cases where ranges become awkward and iterators aren't.


On the other hand, when dealing with algorithms, ranges tend to 
be far cleaner - especially when you need to chain them. And they 
tend to form a better basis of how to think about algorithms 
(even when dealing with iterators, you pretty much have to think 
in terms of ranges on some level at least). And ranges handle 
laziness far better than iterators do. So, I'm not the least bit 
convinced that iterators are a better way to go (quite the 
opposite), and I'm not convinced that trying to mix iterators and 
ranges is at all a good idea. But I do think that it's clear that 
using only ranges is not without its downsides, and since we're 
the first folks to seriously use ranges heavily in a language or 
standard library, we're bound to be making mistakes due to 
inexperience. At this point, I would guess that trying to mix 
iterators and ranges is just going to over-complicate things in 
an already over-complicated language, but it may actually be a 
big win for the C++ folks. We'll have to wait and see.


If we _were_ to look at doing something more than straight 
ranges, we'd probably look more at something like Steven's 
cursors than adding iterators, though I think that there's a 
decent chance that that only really helps with containers (it's 
been a while since I looked at what he did with cursors, and I 
really don't remember the details), though for the most part, I 
think that containers are the primary place where ranges tend to 
get annoying. Algorithms where they're problematic do exist, but 
they seem to be rare.


- Jonathan M Davis

Re: Categorizing Ranges

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 16:54:00 UTC, Meta wrote:

On Wednesday, 7 October 2015 at 15:06:55 UTC, Mike Parker wrote:
I'm looking for ideas on how to label the ranges returned from 
take and drop. Some examples of what I think are appropriate 
categories for other types of ranges:


Generative - iota, recurrence, sequence
Compositional - chain, roundRobin, transposed
Iterative - retro, stride, lockstep
XXX - take, drop

What to put into the XXX? I first thought of "Greedy", but 
that has an association with "greedy algorithms" that I don't 
really like. That led to "Selfish", but it's admittedly not 
that appropriate. Beyond that, I'm stuck. Any and all ideas 
appreciated.


Mutating.


Except that take doesn't mutate its function argument, and drop 
only does if the range is a reference type. So, they really 
aren't mutating algorithms.


- Jonathan M Davis

Re: D 2015/2016 Vision?

[Atila Neves via Digitalmars-d]

On Wednesday, 7 October 2015 at 17:02:51 UTC, Paulo Pinto wrote:
On Wednesday, 7 October 2015 at 15:42:57 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 7 October 2015 at 13:15:11 UTC, Paulo Pinto 
wrote:
In general, I advocate any form of automatic memory/resource 
management. With substructural type systems now being my 
favorite, but they still have an uphill battle for adoption.


Are you thinking about Rust, or some other language?



All of the ones that explore this area. Rust, ATS, Idris, F*


Also as a note, Microsoft will be discussing their proposed 
C++ solution with the Rust team.


Are you thinking about more lintish tools that can give false 
positives, or something with guarantees that can be a language 
feature?


What Herb Sutter demoed at CppCon as compiler validation to 
CoreC++.


I can imagine that depending on how well the community takes 
those guidelines, they might become part of C++20.


On the other hand, on Herb's talk around 1% of the audience 
acknowledged the use of static analysers. Pretty much in sync 
what I see in enterprise developers.


The CppCon demos were impressive, but I'm dying to see how 
Microsoft's analyser works out in real life. I've seen too many 
tools with too many false positives to be useful, and I'm 
sceptical that a library solution is all it takes to make C++ 
safe. As I asked Bjarne after his keynote, if it were that easy, 
why does Rust exist?


Atila

Re: Categorizing Ranges

[H. S. Teoh via Digitalmars-d]

On Wed, Oct 07, 2015 at 05:15:45PM +, Jonathan M Davis via Digitalmars-d 
wrote:
> On Wednesday, 7 October 2015 at 16:54:00 UTC, Meta wrote:
> >On Wednesday, 7 October 2015 at 15:06:55 UTC, Mike Parker wrote:
> >>I'm looking for ideas on how to label the ranges returned from take
> >>and drop. Some examples of what I think are appropriate categories
> >>for other types of ranges:
> >>
> >>Generative - iota, recurrence, sequence
> >>Compositional - chain, roundRobin, transposed
> >>Iterative - retro, stride, lockstep
> >>XXX - take, drop
> >>
> >>What to put into the XXX? I first thought of "Greedy", but that has
> >>an association with "greedy algorithms" that I don't really like.
> >>That led to "Selfish", but it's admittedly not that appropriate.
> >>Beyond that, I'm stuck. Any and all ideas appreciated.
> >
> >Mutating.
> 
> Except that take doesn't mutate its function argument, and drop only
> does if the range is a reference type. So, they really aren't mutating
> algorithms.
[...]

Sub-ranging?


T

-- 
A program should be written to model the concepts of the task it performs 
rather than the physical world or a process because this maximizes the 
potential for it to be applied to tasks that are conceptually similar and, more 
important, to tasks that have not yet been conceived. -- Michael B. Allen

Re: D and microservices

[Atila Neves via Digitalmars-d]

On Wednesday, 7 October 2015 at 10:48:02 UTC, Russel Winder wrote:
On Wed, 2015-10-07 at 07:15 +, extrawurst via Digitalmars-d 
wrote:

[…]

I have never used Go, but isn't what you describe exactly what 
vibe.d is doing using Fibers ?


As I understand it, vibe.d is a single threaded event-loop with 
fibres. In this sense it is equivalent in architecture to Node 
except that vibe.d allows for blocking fibres where Node 
required non-blocking approaches. Thus I would choose vibe.d 
over Node any day, except…


vibe.d supports multiple threads and will schedule tasks on 
separate threads if asked to. Each of those threads will in turn 
have several fibres. The main difference from Go's runtime for me 
are twofold:


1. vibe.d is a library, goroutines are part of the library
2. vibe.d (like D itself) uses the actor model, go is (sort of, 
according to some) CSP


My "Go vs D vs C vs Erlang" MQTT shootout was based on a 
colleague claiming that Go would win because concurrency is its 
thing. I called his bluff since despite Go having a (AFAIK) very 
good scheduler, I didn't see how vibe.d wouldn't give me the same 
performance. I was right.


Atila

[Issue 15037] method TypeInfo.init shadows built-in init property

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15037

ag0ae...@gmail.com changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Pull request to start fixing this by renaming the method to "initializer":
https://github.com/D-Programming-Language/druntime/pull/1403

--

Re: Categorizing Ranges

[Ali Çehreli via Digitalmars-d]

On 10/07/2015 09:15 AM, Mike Parker wrote:

On Wednesday, 7 October 2015 at 15:43:44 UTC, Ali Çehreli wrote:


Something like shortening, minimizing?

Ali


How about reductive?



That's what I had in mind when I started thesaurusing for the other two. :)

Ali