gmane.comp.lang.d.general

Re: D on next-gen consoles and for game development

Jonathan M Davis — 2013-05-23T23:02:00

We have std.typecons.RefCounted, which is basically a shared pointer.


delete is only used for GC memory, and manual memory management should really 
be done with malloc and free rather than explicitly freeing GC memory. But if 
you really want to risk blowing your foot off, you can always use destroy to 
destroy an object in GC memory and core.memory.GC.free to free it.

Also, once we get custom allocators, it should be easier to manually manage 
memory (e.g. I would assume that it would properly abstract doing malloc and 
then emplacing the object in that memory so that you do something like 
allocator!MyObject(args) rather than having to deal with emplace directly).

- Jonathan M Davis

Best XML Library

Meta — 2013-05-23T22:22:24

I'm thinking of starting on a small XMPP-based messaging client 
and server, which would necessitate quite an extensive use of 
XML. Since Tango is no longer being maintained, and Vibe.d 
doesn't support XML (as far as I know), what would be the best 
option for XML capabilities?

Re: primitive value overflow

Marco Leise — 2013-05-23T22:02:27

Am Thu, 23 May 2013 19:55:36 +0200
schrieb luka8088 <luka8088< at >owave.net>:

 
Ok, I remember that from Delphi
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsoverflowchecking_xml.html
It is a good idea and probably better then some Checked!int
construct. Overflows are only wanted in a few places, so it
makes sense to have this check enabled globally and to disable
it for some code locally.

Re: D on next-gen consoles and for game development

Joseph Rushton Wakeling — 2013-05-23T21:42:55

I'm also in agreement with Manu.  There may well already be bugs for some of
them -- e.g. there is one for toUpperInPlace which he referred to, and the
source of the allocation is clear and is even responsible for other bugs:
http://d.puremagic.com/issues/show_bug.cgi?id=9629

I asked for a list because, even if all the cases are registered as bugs, it's
not necessarily easy to find them.  So, we need to either tag all the bugs so
they can be found easily, or make a list somewhere.

Re: D stability testing framework

Kiith-Sa — 2013-05-23T21:39:20

D:YAML might be of use if needed.

There's been no release in recent past (featureset has not 
changed, which I'm still planning for a release), but I've been 
maintaining its compatibility with current DMD for a while and I 
have no intention to stop in forseeable future as I use it in 
pretty much every project I start.

It's somewhere around 10-20kLOC.

https://github.com/kiith-sa/D-YAML


Also, Derelict3 might be a good idea. Derelict has been actively 
maintained for pretty much most of D's history.

Re: D on next-gen consoles and for game development

Paulo Pinto — 2013-05-23T21:37:53

Am 23.05.2013 20:13, schrieb Brad Anderson:

With the increase usage of Windows Phone 8 (I know I know), MonoGame, 
Unity3D and now PS Vita, C# usage is also increasing, so there is a risk 
of D losing that train, even with Remedy's good example.

Please note that on those scenarios, C# is also compiled to native code.

--
Paulo

Re: D stability testing framework

Joseph Rushton Wakeling — 2013-05-23T21:26:37

I'm not familiar with them and didn't know their maintenance status, otherwise
I'd have suggested both.  I was also wondering about your dvm and/or orbit ... ?

Re: D on next-gen consoles and for game development

QAston — 2013-05-23T21:00:08

Thank you very much for the reply - I didn't realize those were 
already there.

Re: Nightly Builds and Better Download Package

Brad Roberts — 2013-05-23T21:00:27

Ignore the auto-tester.. it's a non-issue until there's make targets 
that do the job.  Having it run make install a few times and uploading 
the results somewhere are easy.

Re: D on next-gen consoles and for game development

Dmitry Olshansky — 2013-05-23T20:55:17

23-May-2013 22:13, Brad Anderson пишет:

I have simple and future proof proposal:

1. Acknowledge how containers would look like (API level is fine, and 
std.container has it). Postpone allocator or consider them be backed 
into container.

2. Then for any function that has to allocate something (array 
typically) add a compile-time parameter - container to use. Obviously 
there has to be a constraint on what kind of operations it must provide.

3. std.algorithm and std.range become usable. We then can extend this 
policy beyond.

Some examples to boot:

1. std.array.array - incredibly nice tool, turns any range into array.
Let's make a construct function that does the same for any container:
auto arr = array(iota(0, 10).map....)
--->
auto arr = construct!(Array!int)(iota(0, 10).map...)

by repeatedly calling insertAny in general, and doing better things 
depending on the primitives available (like reserving space beforehand 
for array-like types).

BTW users can use alias FTW:
alias toArray = construct

Re: D on next-gen consoles and for game development

Brad Anderson — 2013-05-23T20:51:41

There is std.typecons.Unique and std.typecons.RefCounted.  Unique 
is more cumbersome than unique_ptr but it should work though I've 
never tried to use it.  Proper rvalue references would be a nice 
improvement here.

RefCounted doesn't support classes yet simply because nobody has 
taken the time to add support for them.

It'd be nice to just be able to say shared_ptr = RefCounted, 
unique_ptr = Unique when somebody asks about smart pointers in D 
though.

std.typecons.scoped is also useful but a bit buggy/cumbersome.  
jA_cOp (IRC handle) is working on improving it.  Manu tried his 
hand at implementing his own version for fun (which came up 
because we were engaged in yet another GC argument with someone 
coming from C++).

Re: Nightly Builds and Better Download Package

nazriel — 2013-05-23T20:50:31


Back to the main topic.

Walter is there any way we could help with improving packaging?

I guess for the first one the fastest way will be to make pull 
request for pull-tester and make consultation with bradd.

But AFAIK second one depends mostly on you.
It's really pain to download 20MB each time I need to install 
DMD... 5MB would be the max package size if we split OS versions.

And yeah, I move alot so downloading 20MB takes some time with my 
UMTS modem :)

Re: Nightly Builds and Better Download Package

Walter Bright — 2013-05-23T20:45:29

No, it isn't closed source any more than "zip" is closed source.

Re: D on next-gen consoles and for game development

H. S. Teoh — 2013-05-23T20:21:12

Please file a bug on the bugtracker to update memory.html to reflect
current usage. Misleading (or outdated) documentation is often worse
than no documentation.


T

Re: D on next-gen consoles and for game development

QAston — 2013-05-23T20:18:36

Sorry, should be:
Maybe even place the malloc-howto in Efficency paragraph of main 
website.

Re: D on next-gen consoles and for game development

QAston — 2013-05-23T20:15:50

On Thursday, 23 May 2013 at 20:07:08 UTC, Steven Schveighoffer 
wrote:

Yes, I know the rationale behind deprecating delete and i agree 
with it. But from newcomer's point of view this looks misleading 
- not everyone has enough patience (or hatered towards c++) to 
lurk inside mailing lists and official website shows the 
deprecated way of doing things: http://dlang.org/memory.html . 
IMO manual memory management howto should be in a visible place - 
to dispell the myths language suffers from. Maybe even place in 
to the malloc-howto in Efficency paragraph of main website.

Re: D on next-gen consoles and for game development

Jonathan M Davis — 2013-05-23T20:14:39

Presumably, we'll get that with custom allocators. So, it's probably just a 
question of how long it'll take to sort those out.

- Jonathan M Davis

Re: D on next-gen consoles and for game development

Steven Schveighoffer — 2013-05-23T20:07:06


While I'm not specifically addressing the ability or not to disable the GC  
(I agree D has problems tehre), deprecating the delete operator does NOT  
preclude manual memory management.

The problem with delete is it conflates destruction with deallocation.   
Yes, when you deallocate, you want to destroy, but manual deallocation is  
a very dangerous operation.  Most of the time, you want to destroy WITHOUT  
deallocating (this is for cases where you are relying on the GC).

Then I think Andrei also had a gripe that D had a whole keyword dedicated  
to an unsafe operation.

You can still destroy and deallocate with destroy() and GC.free().

-Steve

Re: D on next-gen consoles and for game development

Nick Sabalausky — 2013-05-23T20:06:01

On Thu, 23 May 2013 21:37:26 +0200
"Kiith-Sa" <kiithsacmp< at >gmail.com> wrote:


I'd like to hear an official confirmation (or denial) at this point,
too (assuming Remedy is at a point where they're comfortable making a
statement on the matter - and after all, it would make sense if
they're still keeping open the possibility of backing out of D for
whatever they're using it on by release if they end up needing to do so,
even if such a possibility is very unlikely).

However, I do think it's a safe bet: Like Brad said, Remedy is a
relatively small dev company that doesn't have a history of working on
multiple AAA titles simultaneously. They *are* known to have one other
mystery title besides Quantum Break in development, but it's for iOS -
so it's not a AAA title, and it's definitely not x86, so that one can
definitely be ruled out (unless Manu was messing with us to keep
it super-secret ;) ).

As far as I'm concerned, the whole "Quantum Break uses D" thing *is*
technically a rumor, and I think it's probably bes

Re: D on next-gen consoles and for game development

QAston — 2013-05-23T20:02:05

I think that Phobos should have some support for manual memory 
management. I don't mean clearing out the gc usage there, as it's 
fairly obvious. I rather think about something like 
unique_ptr/shared_ptr in the std. I think unique_ptr can't be 
implemented without rval refs, also C++ sollutions may not fit 
here. Anyways, now it's not so straightforward how to live 
without gc so standard sollution would be really helpful.

Also, it should be visible in C++/D that D can really deal with 
manual memory management conveniently - when I checked out Dlang 
first time I felt very disappointed that "delete" operator is 
deprecated. "So - they advertise one can code without GC, yet 
they seem to deprecate the operator" - false claims discourage 
people from using new languages.

Re: D on next-gen consoles and for game development

Piotr Szturmaj — 2013-05-23T19:58:32

W dniu 23.05.2013 20:13, Brad Anderson pisze:

When I started learning D 2 years ago, I read on the D webpage that D
allows manual memory management and it's possible to disable the GC. My
first thought was that standard library is written without using GC.
This could be kind of lowest common denominator solution to the
problem. Later, I found it was only my wishful thinking. So, you can
disable GC, but then you can't reliably use the standard library.

Lowest common denominator has its own weaknesses, mainly it sometimes
sacrifices performance, as some algorithms may perform better using
managed slices for example, than using manually managed memory.

nogc attribute could be used to not only block GC, it could be used to
select between GC and non-GC code with the help of the overloading
mechanism. So, the programmer instead of writing one function, would
actually write two functions, one for the GC and one for manual memory
management - only if they need separete code. This will surely double
the effort for