Manu via Digitalmars-d | 2 Oct 08:02 2014

Mike Acton at CppCon (prominent game-dev lecture to non-game-dev's)

I just thought I'd drop this here for peoples interest.

It occurred to me that I usually take this sort of thing separately to
my interest in D, but since there are few gamedev's here, and I often
have trouble attracting sympathy for our industry concerns, this might
give some window into the way we think, and tend to approach...
basically everything.

Mike is a super well known (and outspoken) engine dev, every gamedev
knows who he is.
What he's presenting here to CppCon is something that we've been doing
pervasively for 10-15 years.
It's all fairly basic and obvious, but all-too-often ignored.
You can see the focus on codegen and low-level performance, and how
much attention we tend to pay to it :)
This leads into things like, for instance, why I'm so fussy about
things like very highly-controlled handling of ref, and
final-by-default.

https://www.youtube.com/watch?v=rX0ItVEVjHc&feature=youtu.be

Re: Program logic bugs vs input/environmental errors (checked exceptions)

On Wednesday, 1 October 2014 at 22:42:27 UTC, Jeremy Powers via
Digitalmars-d wrote:
>
> If you see "throws Exception" in java code chances are the code 
> is broken,
> same as if you see "catch (Exception" - this tells you nothing 
> about the
> exception that happened, and hence you can do nothing with it.  
> So you
> either swallow (and silently break in many cases) or rethrow 
> (and break for things you needn't have).  As mentioned, the 
> standard way to avoid this is to have a parent exception type 
> appropriate to the abstraction in the API, and throw subtypes 
> in the implementation.  Among other things, this means you can 
> change the implementation to throw different exceptions without 
> breaking any users (who will already be catching the parent 
> exception).

...while in Phobos, most of the subtyped exceptions were
eliminated a while back in favor of just always throwing
Exception.

Re: RFC: moving forward with <at> nogc Phobos

On 10/1/14, 10:51 AM, H. S. Teoh via Digitalmars-d wrote:
> But Sean's idea only takes strings into account. Strings aren't the only
> allocated resource Phobos needs to deal with. So extrapolating from that
> idea, each memory management struct (or whatever other aggregate we end
> up using), say call it MMP, will have to define MMP.string, MMP.jsonNode
> (since parseJSON() need to allocate not only strings but JSON nodes),
> MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ...
>
> Nope, still don't see how this could work. Please clarify, kthx.

There's management for T[], pointers to structs, pointers to class 
objects, associative arrays, and that covers everything. -- Andrei

Re: RFC: moving forward with <at> nogc Phobos

On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
>
> But Sean's idea only takes strings into account. Strings aren't 
> the only
> allocated resource Phobos needs to deal with. So extrapolating 
> from that
> idea, each memory management struct (or whatever other 
> aggregate we end
> up using), say call it MMP, will have to define MMP.string, 
> MMP.jsonNode
> (since parseJSON() need to allocate not only strings but JSON 
> nodes),
> MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ...
>
> Nope, still don't see how this could work. Please clarify, kthx.

Assuming you're willing to take the memoryModel type as a
template argument, I imagine we could do something where the user
can specialize the memoryModel for their own types, a bit like
how information is derived for iterators in C++.  The problem is
that this still means passing the memoryModel in as a template
argument.  What I'd really want is for it to be a global, except
that templated virtuals is logically impossible.  I guess
something could maybe be sorted out via a factory design, but
that's not terribly D-like.  I'm at a loss for how to make this
memoryModel thing work the way I'd actually want it to if I were
to use it.

(Continue reading)

Kiith-Sa via Digitalmars-d | 1 Oct 20:28 2014

Re: RFC: moving forward with <at> nogc Phobos

On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Wed, Oct 01, 2014 at 02:51:08AM -0700, Andrei Alexandrescu 
> via Digitalmars-d wrote:
>> On 9/30/14, 11:06 AM, Dmitry Olshansky wrote:
>> >29-Sep-2014 14:49, Andrei Alexandrescu пишет:
>> >>auto setExtension(MemoryManagementPolicy mmp = gc, R1, 
>> >>R2)(R1 path, R2
>> >>ext)
>> >>if (...)
>> >>{
>> >>     static if (mmp == gc) alias S = string;
>> >>     else alias S = RCString;
>> >>     S result;
>> >>     ...
>> >>     return result;
>> >>}
>> >
>> >Incredible code bloat? Boilerplate in each function for the 
>> >win?
>> >I'm at loss as to how it would make things better.
>> 
>> Sean's idea to make string an alias of the policy takes care 
>> of this
>> concern. -- Andrei
>
> But Sean's idea only takes strings into account. Strings aren't 
> the only
> allocated resource Phobos needs to deal with. So extrapolating 
> from that
(Continue reading)

Dicebot via Digitalmars-d | 1 Oct 19:32 2014

Re: FOSDEM'15 - let us propose a D dev room!!!

I think I will attend anyway as a casual visitor, can have an 
informal D meetup at least.

Re: Program logic bugs vs input/environmental errors

On 10/1/14 11:00 AM, Andrej Mitrovic via Digitalmars-d wrote:
> On 10/1/14, Steven Schveighoffer via Digitalmars-d
> <digitalmars-d <at> puremagic.com> wrote:
>> No, this is lazy/incorrect coding. You don't want your user to see an
>> indecipherable stack trace on purpose.
>
> So when they file a bug report are you going to also ask them to run
> the debugger so they capture the stack trace and file that to you?
> Come on.
>

No what I mean is:

./niftyapp badfilename.txt

Result should be:

Error: Could not open badfilename.txt, please check and make sure the 
file exists and is readable.

Not:

std.exception.ErrnoException <at> std/stdio.d(345): Cannot open file 
`badfilename.txt' in mode `rb' (No such file or directory)
----------------
5   testexception                       0x0000000104fad02d ref 
std.stdio.File std.stdio.File.__ctor(immutable(char)[], const(char[])) + 97
6   testexception                       0x0000000104f8d735 _Dmain + 69
7   testexception                       0x0000000104f9f771 void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
(Continue reading)

std.utf.decode <at> nogc please

lately when working on std.string I run into problems making 
stuff nogc as std.utf.decode is not nogc.

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

Also I would like a version of decode that takes the string not 
as ref.

Something like:

bool decode2(S,C)(S str, out C ret, out size_t strSliceIdx)
     if(isSomeString!S && isSomeChar!C) {}

where true is returned if the decode worked and false otherwise.

Ideas, Suggestions ... ? any takers?

Re: RFC: moving forward with <at> nogc Phobos

On 9/30/14, 6:53 PM, Manu via Digitalmars-d wrote:
> I generally like the idea, but my immediate concern is that it implies
> that every function that may deal with allocation is a template.
> This interferes with C/C++ compatibility in a pretty big way. Or more
> generally, the idea of a lib. Does this mean that a lib will be
> required to produce code for every permutation of functions according
> to memory management strategy? Usually libs don't contain code for
> uninstantiated templates.

If a lib chooses one specific memory management policy, it can of course 
be non-templated with regard to that. If it wants to offer its users the 
choice, it would probably have to offer some templates.

> With this in place, I worry that traditional use of libs, separate
> compilation, external language linkage, etc, all become very
> problematic.
> Pervasive templates can only work well if all code is D code, and if
> all code is compiled together.
> Most non-OSS industry doesn't ship source, they ship libs. And if libs
> are to become impractical, then dependencies become a problem; instead
> of linking libphobos.so, you pretty much have to compile phobos
> together with your app (already basically true for phobos, but it's
> fairly unique).
> What if that were a much larger library? What if you have 10s of
> dependencies all distributed in this manner? Does it scale?
>
> I guess this doesn't matter if this is only a proposal for phobos...
> but I suspect the pattern will become pervasive if it works, and yeah,
> I'm not sure where that leads.

(Continue reading)

Re: RFC: moving forward with <at> nogc Phobos

On 9/30/14, 10:33 AM, H. S. Teoh via Digitalmars-d wrote:
> Yeah, this echoes my concern. This looks not that much different, from a
> user's POV, from C++ containers' allocator template parameters. Yes I
> know we're not talking about*allocators*  per se but about *memory
> management*, but I'm talking about the need to explicitly pass mmp to
> *every*  *single*  *function*  if you desire anything but the default. How
> many people actually*use*  the allocator parameter in STL? Certainly,
> many people do... but the code is anything but readable / maintainable.

The parallel with STL allocators is interesting, but I'm not worried 
about it that much. I don't want to go off on a tangent but I'm fairly 
certain std::allocator is hard to use for entirely different reasons 
than the intended use patterns of MemoryManagementPolicy.

> Not only that, but every single function will have to handle this
> parameter somehow, and if static if's at the top of the function is what
> we're starting with, I fear seeing what we end up with.

Apparently Sean's idea would take care of that.

> Furthermore, in order for this to actually work, it has to be percolated
> throughout the entire codebase -- any D library that even remotely uses
> Phobos for anything will have to percolate this parameter throughout its
> API -- at least, any part of the API that might potentially use a Phobos
> function.

Yes, but that's entirely expected. We're adding genuinely new 
functionality to Phobos.

> Otherwise, you still have the situation where a given D
(Continue reading)

How to build phobos docs for dlang.org

I am in the process of working on some documentation improvements 
for Phobos. I am running into an issue while testing. Namely, I 
do not know how to build the ddocs for Phobos in quite the way 
that dlang.org does.

I can build them with: posix.mak -f DMD=TheRightOne html

But everything is poorly formatted, and more importantly, there's 
some wizardry going on to make std.container look like one file 
on dlang.org and I therefore cannot find out how to preview my 
changes to the several files that actually compose that package. 
In other words, if I go to the page for std_string.html, it works 
perfectly, but if I try go to std_container.html, it does not 
exist because there is no container.d file.

If I build dlang.org separately, I cannot follow the library 
reference link. The makefile for dlang.org includes rules for 
phobos-release and phobos-prerelease, but as far as I can tell, 
this does not generate the content I need (or I am not able to 
easily find it). If I copy the fully-built phobos html build into 
dlang.org/web/phobos then I can see the pages with the familiar 
dlang.org color scheme and layouts, but std_container.html still 
does not exist, and that is my fundamental problem.

This should really be documented somewhere. If nowhere else, this 
file seems appropriate: 
https://github.com/D-Programming-Language/dlang.org/blob/master/CONTRIBUTING.md

I hereby volunteer to document whatever answer I am given.

(Continue reading)


Gmane