rakpenak via Digitalmars-d | 31 Oct 07:22 2014

Budget Kitchens London

Budget Kitchens London. Thirty Ex Display Kitchens To Clear. w w 
w. e x d i s p l a y k i t c h e n s 1. c o. u k £ 595 Each with 
appliances.Tel 01616-694785

D wrapper classes leak memory. Next steps?

GtkD wraps all the objects in Gtk. In callbacks like "onDraw",
when they are called often, this creates heaps of tiny wrapper
objects around huge data from C libraries. Eventually system
memory is exhausted and the computer slows down and eats into
swap. So should we add a "run garbage collector" button to
every application to clean those up? Seems rather silly.

The GC should stick to its own memory and not try to manage
resources it doesn't understand. Reference counting applies to
external and system resources much better. To date neither the
language nor Phobos can ref count classes. And even with
library support it is not likely that it will get used widely,
because plain classes are so much easier (also on the eyes).

The extent of this is pretty huge. There are many D wrapper
libraries that build on classes and mimic what is available
for C++ or Python. Issues like this make D appear like a toy
language. How would one write a big desktop application when
a simple animation can exhaust system memory in seconds ?

--

-- 
Marco

Re: C++ developer choices in open source projects

On 10/30/2014 1:04 PM, H. S. Teoh via Digitalmars-d wrote:
> D has ruined my life, I just can't go back to C++ anymore...

Ehhhxcellleeeennnntt!

http://www.gocurrycracker.com/wp-content/uploads/2014/07/cm-23138-050624abe3a9e6.jpeg

Re: What IDE/EDITOR do you use for D?

On Thursday, 30 October 2014 at 16:58:49 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> And I do use ctags every now and then for navigating between 
> functions.

In case you didn't know, dscanner has a "--ctags" flag for 
generating tags from D files.

Re: C++ developer choices in open source projects

Am 30.10.2014 um 21:04 schrieb H. S. Teoh via Digitalmars-d:
> On Thu, Oct 30, 2014 at 03:52:51PM +0000, Atila Neves via Digitalmars-d
> wrote: [...]
>>> CERN remains at the centre of so much good software development.
>>> Which is why they use Python.
>>
>> Wait, what? Good software development? At CERN?? Really??? As a friend
>> of mine one put it:
>>
>> "At CERN, 10% of people writing code know what they're doing, 45%
>> don't know what they're doing but are aware of it, and 45% don't know
>> what they're doing but think they do because software development is
>> 'so much easier than Physics'".
>>
>> I've seen recently (as in weeks ago) written Python code from ATLAS.
>> It's so atrocious it doesn't even look like Python. Most people I know
>> still working at CERN don't even know what C++11 is, much less use it.
> [...]
>
> It's probably a good thing they don't know what C++11 is, otherwise they
> might start writing even more horrendous code using operator""(). I
> suppose I've been a frog in the well, but it was only yesterday when I
> discovered that C++11 allows user-defined literals via operator""().
> Skimming over the docs for that today, I couldn't help but shake my head
> at just how wrong the whole conception of it is. It's just *asking* to
> be abused for writing inscrutable, unreadable, unmaintainable code. I
> honestly have trouble imagining any sane use case for it apart from
> submitting obfuscated code contest entries. But hey, what's one more
> nail in a coffin already crawling with monstrosities like
> Boost.Xpressive?
(Continue reading)

Re: C++ developer choices in open source projects

>> The only two workplaces I was allowed to use C++ properly was 
>> at CERN and at a startup on a C#/C integration project done 
>> via Managed C++.

Well, at CERN, "allowed" mostly because nearly everybody writes 
code for themselves only and people do whatever they want to do. 
Never mind that there's no common CERN-wise codebase that isn't 
called ROOT.

>
> CERN remains at the centre of so much good software 
> development. Which
> is why they use Python.

Wait, what? Good software development? At CERN?? Really??? As a 
friend of mine one put it:

"At CERN, 10% of people writing code know what they're doing, 45% 
don't know what they're doing but are aware of it, and 45% don't 
know what they're doing but think they do because software 
development is 'so much easier than Physics'".

I've seen recently (as in weeks ago) written Python code from 
ATLAS. It's so atrocious it doesn't even look like Python. Most 
people I know still working at CERN don't even know what C++11 
is, much less use it.

Atila

(Continue reading)

Re: toString refactor in druntime

On 10/28/14 7:06 PM, Manu via Digitalmars-d wrote:
> On 28 October 2014 22:51, Steven Schveighoffer via Digitalmars-d
> <digitalmars-d <at> puremagic.com> wrote:
>> On 10/27/14 8:01 PM, Manu via Digitalmars-d wrote:
>>>
>>>    28 October 2014 04:40, Benjamin Thaut via Digitalmars-d
>>> <digitalmars-d <at> puremagic.com> wrote:
>>>>
>>>> Am 27.10.2014 11:07, schrieb Daniel Murphy:
>>>>
>>>>> "Benjamin Thaut"  wrote in message news:m2kt16$2566$1 <at> digitalmars.com...
>>>>>>
>>>>>>
>>>>>> I'm planning on doing a pull request for druntime which rewrites every
>>>>>> toString function within druntime to use the new sink signature. That
>>>>>> way druntime would cause a lot less allocations which end up beeing
>>>>>> garbage right away. Are there any objections against doing so? Any
>>>>>> reasons why such a pull request would not get accepted?
>>>>>
>>>>>
>>>>>
>>>>> How ugly is it going to be, since druntime can't use std.format?
>>>>
>>>>
>>>>
>>>> They wouldn't get any uglier than they already are, because the current
>>>> toString functions within druntime also can't use std.format.
>>>>
>>>> An example would be to toString function of TypInfo_StaticArray:
>>>>
(Continue reading)

Less Code Bloat from Templates

I'm not sure what the status is on this, I remember Walter saying 
in a conference (DConf 2014 I think) that he had an idea to 
remove duplicate template instantiations by comparing their 
generated code but I had another idea I thought I'd share.

I'm calling the idea "CombinationTypes".  Sort of a 
"compile-time" concept that allows code to use multiple types 
that would produce the same binary code but retains type 
information.  The first combination type I would introduce is the 
"any*" or "any[]" types. For example, you could write the 
following function:

any* limitPtr(any[] array) {
   return any.ptr + any.length;
}

The advantage of using a combination type like "any" over say 
"void" is the compiler knows what you are trying to do and won't 
require you to perform any awkward casting.  The following code 
should work fine:

char[] mychars;
string mystring;

auto mycharsLimit = mychars.limitPtr; // mycharsLimit is a char*
auto mystringLimit = mystring.limitPtr; // mystringLimit is a 
immutable(char)*

The generated code for this function will be identical no matter 
what the element type is.  The problem with using a template is 
(Continue reading)

via Digitalmars-d | 30 Oct 06:54 2014

Re: What IDE/EDITOR do you use for D?

On Thursday, 30 October 2014 at 05:01:27 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> templates and metaprogramming completely. I was skimming over 
> Google's
> C++ style guide today, for example, and was shocked to discover 
> that
> they discourage the use of templates and frown on 
> metaprogramming, among
> other shocking things (like prohibiting exceptions, using 
> 2-space
> indentation, and other "interesting" things [1]).

The Google cppcon presentation was pretty clear on this, e.g.:

1. The code should be easy to understand at the call site for a 
non-expert. No need to look up the docs. They don't care if code 
is tedious to write, because reading is more important and 
frequent.

2. Exceptions hide error_handling, so they have their own status 
class that force error-handling or explicit "ignore()" to make 
code review easier. C++ exceptions also come with a performance 
penalty.

3. No non-const ref parameters to functions, use pointers. They 
want a visible "&" at call site for output parameters. e.g. 
"read(&var)" so that you don't have to look the function up in 
the docs.

4. They use clang with C++11 and standard libraries.
(Continue reading)

Xinok via Digitalmars-d | 30 Oct 01:19 2014

Re: DIP67: Associative Ranges

On Thursday, 30 October 2014 at 00:10:47 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Wed, Oct 29, 2014 at 11:33:53PM +0000, Freddy via 
> Digitalmars-d wrote:
>> On Wednesday, 29 October 2014 at 19:55:14 UTC, H. S. Teoh via
>> Digitalmars-d wrote:
> [...]
>> >And how would it be implemented in a way that is stable 
>> >across AA
>> >implementations?
>> >
>> >
>> >--T
>> in std.range
>> ----
>> auto byKeyPair(R)(R r) if(isAssociativeRange!R){
>> 	return zip(r.byKey,r.byValue);
>> }
>> ----
>
> This is not stable across AA implementations.  There is no 
> guarantee
> that byKey and byValue will return elements in the same order. 
> The
> current implementation does, but it's a shaky assumption.

It's already covered by the DIP. Simply, it's one of the 
requirements of an associative range: "byKey and byValue must be 
align to the same Pair when iterating." While the compiler can't 
enforce this, there are many things about ranges which the 
(Continue reading)

Freddy via Digitalmars-d | 30 Oct 00:33 2014

Re: DIP67: Associative Ranges

On Wednesday, 29 October 2014 at 19:55:14 UTC, H. S. Teoh via
Digitalmars-d wrote:
> On Wed, Oct 29, 2014 at 06:40:50PM +0000, Freddy via 
> Digitalmars-d wrote:
>> On Wednesday, 29 October 2014 at 18:04:30 UTC, John Colvin 
>> wrote:
>> >On Wednesday, 29 October 2014 at 17:36:41 UTC, H. S. Teoh via
>> >Digitalmars-d wrote:
> [...]
>> >>I've submitted a PR for byPair before, but it was 
>> >>roadblocked by the
>> >>fact that people demand that it return std.typecons.Tuple, 
>> >>yet we're
>> >>not allowed to import Phobos in druntime. Other than this IMO
>> >>nitpicky issue, the code was already all ready to go many 
>> >>moons ago.
>> >>
>> >>
>> >>T
>> >
>> >Can byPair be implemented in phobos, or does it need to access
>> >private/package stuff in druntime?
>> 
>> I don't see why not,It could be put into std.range and accept a
>> generic associative range(which includes the build-in 
>> associative
>> array).
>
> And how would it be implemented in a way that is stable across 
> AA
(Continue reading)


Gmane