<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.d.general">
    <title>gmane.comp.lang.d.general</title>
    <link>http://blog.gmane.org/gmane.comp.lang.d.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88999"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88908"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88885"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88789"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88788"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88783"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88764"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88716"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88705"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88639"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88630"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88621"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88590"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88588"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88579"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88551"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88549"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88536"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88513"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.d.general/88499"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88999">
    <title>dbuilder, pakage manager, dget</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88999</link>
    <description>&lt;pre&gt;Dear, 

dbuilder: https://github.com/dbuilder-developers/dbuilder

currently dbuilder works on Linux, Apple, Windows platform (at least)
this tool allow to us to build easily lib, or desktop application
It support // build, // install
i think i will improve this tool to be use as a package manager, for
this add to supported config file a new section
---
[[dependenies]]
[[[xxx]
version_type=[version, tag, revision]
repo_url=https://github ...https://bitbucket ...
tool=[git, hg, svn]
version=xx
tag=xx
revision=xx
---

put the config file at root of repo for detect this file and use it

if this config is not enough for to be used as config said to me what
need to be added

anyone is welcome


&lt;/pre&gt;</description>
    <dc:creator>bioinfornatics</dc:creator>
    <dc:date>2012-05-26T11:34:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88908">
    <title>clear() and UFCS</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88908</link>
    <description>&lt;pre&gt;So I was writing a container class and in some test code, I called 
container.clear(). Reasonable enough, right? Hell, it even compiled!

Turns out, my program completely broke at runtime. Apparently, I'd 
forgotten to implement clear() on my container class, and 
*object.clear() was being called instead*.

I don't blame UFCS for this. It just happened to be the reason this 
compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST 
HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an 
object. Did it not seem obvious to call it, I don't know, *finalize*? 
And even ignoring the naming, having a symbol called clear in the 
'global' namespace is absolute insanity.

Am I the only person with this opinion?

&lt;/pre&gt;</description>
    <dc:creator>Alex Rønne Petersen</dc:creator>
    <dc:date>2012-05-25T13:04:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88885">
    <title>Pointer semantics in CTFE</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88885</link>
    <description>&lt;pre&gt;The current implementation of CTFE strictly enforces C pointer 
semantics. One of the restrictions is that you cannot perform ordering 
comparisons between unrelated pointers.
This is important for repeatability: if it was permitted, the results 
would be arbitrary and might vary unpredictably with subtle changes in 
the code, or change between compiler releases.

But, there's an interesting case from bug 7898: the 'inside' operation.
If p and q are pointers to the same array, then (r &amp;gt;= p &amp;amp;&amp;amp; r &amp;lt;= q) is 
true if r points inside that array, and false if it does not.
This seems to be a perfectly reasonable operation: it is completely 
repeatable and safe, regardless of what r points to. But there doesn't 
seem to be any way to rewrite it to avoid the disallowed comparisons.

I could write code to allow this special case in CTFE. There's a bit of 
work to make sure that all the valid cases are detected, because there 
are quite a lot of ways to rewrite it, but it's not too terrible.

But I dunno, I don't like this sort of thing much. Feels a bit clunky.
OTOH it seems like necessary functionality, and I can't see any other 
way of doing it.

Opinions?


&lt;/pre&gt;</description>
    <dc:creator>Don Clugston</dc:creator>
    <dc:date>2012-05-25T06:50:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88789">
    <title>Live code analysis in DCT</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88789</link>
    <description>&lt;pre&gt;http://d-coding.com/2012/05/24/performing-live-analysis-in-dct.html

&lt;/pre&gt;</description>
    <dc:creator>Roman D. Boiko</dc:creator>
    <dc:date>2012-05-24T12:25:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88788">
    <title>Destructor nonsense on dlang.org</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88788</link>
    <description>&lt;pre&gt;Hi,

http://dlang.org/class.html#Destructor

"The garbage collector is not guaranteed to run the destructor for all 
unreferenced objects."

What the *hell*? So resources are allowed to arbitrarily leak and the 
programmer has to actually expect this to happen?

I really, really hope that this is a documentation error or early design 
decision that has since been rectified but with lack of documentation 
updates.

&lt;/pre&gt;</description>
    <dc:creator>Alex Rønne Petersen</dc:creator>
    <dc:date>2012-05-24T12:21:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88783">
    <title>C linkage is fun</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88783</link>
    <description>&lt;pre&gt;Just a little gotcha I ran into today:

import core.memory;

extern (C) void gc_collect()
{
     assert(false, "nope!");
}

void main()
{
     GC.collect();
}

&lt;/pre&gt;</description>
    <dc:creator>Alex Rønne Petersen</dc:creator>
    <dc:date>2012-05-24T12:06:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88764">
    <title>Exception/Error division in D</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88764</link>
    <description>&lt;pre&gt;Let's talk about an abstract situation without caring about breaking 
existing code, current docs, implementation etc.

Definitions:
* an Exception is something that tigers scope guards and executes 
catch/finally blocks if thrown;
* an Error is something that doesn't do it.

As a result _we can't do any clean-up if an Error is thrown_ because 
scope guards and catch/finally blocks aren't executed and the program is 
in invalid state because of this. Of course it's theoretically possible 
to code without scope guards and catch/finally blocks but isn't 
applicably for a real project. E.g. in some editor if and Error is 
thrown there is no ability to save opened documents.


Main Question: What do you think can be an Error?

Can "Integer Divide by Zero" be an Error? Definitely, not.

Can "Access Violation" be an Error? No, because it's very common to 
access a field/virtual member function of a null object.

Can "Out of memory" be an Error? No, because e.g. if I read a user file 
that require me to create a large array (&amp;gt; 100 MiB, e.g.) I don't want 
to crash, but just tell, that "Dear user, the file can't be opened 
because it requires..."


So what am I think can be an Error? IMHO, nothing. Because throwing 
everything can indicate that program in very good/terribly bad state and 
compiler doesn't know anything about that. And because fatal error is 
fatal the program should just try to print error and close instead of 
throwing something.


Let's now return to the real D world. Current implementation treats 
Errors as Exceptions for now. Documentation keeps silence. All listed 
"can't be an error" cases are Errors (and it's terrible).

So why do we has Exception/Error division in D? Because of nothrow. 
Personally I don't need nothrow for that high cost of making D unusable 
for me. Lets realize and solve Exception/Error problem and solve nothrow 
in the second place.


Related links:
http://forum.dlang.org/thread/1566418.J7qGkEti3s&amp;lt; at &amp;gt;lyonel
http://d.puremagic.com/issues/show_bug.cgi?id=8135
http://d.puremagic.com/issues/show_bug.cgi?id=8136
http://d.puremagic.com/issues/show_bug.cgi?id=8137


P.S.
By the way, the only problem I see in current implementation is a luck 
of "Object finalized" assertion ("True disposable objects (add 
"Finalized!" assertion)" NG thread that didn't interest anybody).

&lt;/pre&gt;</description>
    <dc:creator>Denis Shelomovskij</dc:creator>
    <dc:date>2012-05-24T10:27:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88716">
    <title>dget - getting code from github</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88716</link>
    <description>&lt;pre&gt;Currently, getting D code from github is a multistep process, that isn't always 
obvious. I propose the creation of a dget program, which will:

     dget https://github.com/D-Programming-Deimos/libevent

download the libevent code and install it in a subdirectory named libevent. Of 
course, the url could also be:

     dget github.com/D-Programming-Deimos/libevent

since https is assumed, or:

     dget D-Programming-Deimos/libevent

since github is assumed. And since Deimos is a known library,

     dget libevent

can also be hardwired into dget.

Anyone want to implement such? It ought to be fairly straightforward, and will 
be a nice timesaver for a lot of people.

&lt;/pre&gt;</description>
    <dc:creator>Walter Bright</dc:creator>
    <dc:date>2012-05-23T23:14:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88705">
    <title>tuple of ranges - findSplit</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88705</link>
    <description>&lt;pre&gt;I'm currently designing an interface, which conceptually is 
similar to findSplit... so I decided to peek at/learn from 
Phobos...

"findSplit returns a tuple result containing three ranges"

tuple(haystack[0 .. pos1],haystack[pos1 .. pos2], haystack[pos2 
.. haystack.length]);

As one easiliy can spot, pos1 and pos2 occurs twice... in 
isolated cases it doesn't matter, but in my case I was planning 
to generate a number of these.

Hmmm... just wondering, did anyone already design/implement a 
pretty/efficient interface ontop of a structure similar to below?

struct
{
   uint r0;
   union
   {
     uint r1
     uint r2
   }
   union
   {
     uint r3
     uint r4
   }
   uint r5;
}


&lt;/pre&gt;</description>
    <dc:creator>Tove</dc:creator>
    <dc:date>2012-05-23T21:56:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88639">
    <title>Pegged and DMD Compilation Memory</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88639</link>
    <description>&lt;pre&gt;Greetings

I am trying to use Pegged for compile time parsing. The only issue I am
facing is with the compile time memory. I have a rather simple grammar,
mostly derived from the arithmetic.d example that comes bundled with Pegged.

I am wondering if the memory could be optimized by fine-tuning the code in
the grammar that I have written. I am pasting the code down here for
suggestions. On my 64-bit linux machine my small application is taking as
much as 2.2GB of RAM at the time of compiling the code using DMD 2.059. I
am using the latest Pegged code from github.

Regards
- Puneet

mixin(grammar(
   "CstGrammar:
    CstSet     &amp;lt;  Cst+
    Cst        &amp;lt;  Bool ';'
    Bool       &amp;lt;  Comparison BoolExpr*
    BoolExpr   &amp;lt;  ^('&amp;amp;&amp;amp;'/'||') Comparison
    Comparison &amp;lt;  Expr CompExpr?
    CompExpr   &amp;lt;  ^('&amp;lt;='/'&amp;gt;='/'!='/'&amp;lt;'/'&amp;gt;'/'==') Expr
    Expr       &amp;lt;  Factor AddExpr*
    AddExpr    &amp;lt;  ^('+'/'-') Factor
    Factor     &amp;lt;  Primary MulExpr*
    MulExpr    &amp;lt;  ^('*'/'/') Primary
    Primary    &amp;lt;  Parens / Number / Variable / ^'-' Primary
    Parens     &amp;lt;  '(' Bool ')'
    Number     &amp;lt;~ [0-9]+
    Variable   &amp;lt;- Identifier"
));
&lt;/pre&gt;</description>
    <dc:creator>d coder</dc:creator>
    <dc:date>2012-05-23T15:17:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88630">
    <title>Sparse matrix solver libraries</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88630</link>
    <description>&lt;pre&gt;Hi All.

OK. I'm sold on using D to develop an experimental hydrologic 
modeling code, but I need a sparse linear algebra package. Has 
anyone either developed such a package in D or linked to an 
existing C or C++ library? There are a number of existing free 
libraries out there, and I hate to reinvent the wheel. If no such 
D library interface exists, I'm happy to work on one as a 
community project, but I suspect I'll need quite a bit of help. 
Is anybody game for such a project?

THANKS!
--vic

&lt;/pre&gt;</description>
    <dc:creator>Vic Kelson</dc:creator>
    <dc:date>2012-05-23T14:16:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88621">
    <title>Does D have "structural sharing" of immutable collections?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88621</link>
    <description>&lt;pre&gt;Just some beginner questions...

Does D have "structural sharing" of its immutable collections?

i.e. Can I make a copy of an immutable Map or List collection 
with an extra (or mutated) member, and will the returned (new) 
collection share most of it's structure with the earlier 
collection.

Thanks,

Chris.

&lt;/pre&gt;</description>
    <dc:creator>Chris Dew</dc:creator>
    <dc:date>2012-05-23T13:50:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88590">
    <title>forcing weak purity</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88590</link>
    <description>&lt;pre&gt;I have come across a dilemma.

Alex Rønne Petersen has a pull request changing some things in the GC to  
pure.  I think gc_collect() should be weak-pure, because it could  
technically run on any memory allocation (which is already allowed in pure  
functions), and it runs in a context that doesn't really affect execution  
of the pure function.

So I think it should be able to be run inside a strong pure function.  But  
because it has no parameters and no return, marking it as pure makes it  
strong pure, and an optimizing compiler can effectively remove the call  
completely!

So how do we force something to be weak-pure?  What I want is:

1. it can be called from a pure function
2. it will not be optimized out in any way.

This solution looks crappy to me:

void gc_collect(void *unused = null);

any other ideas?

-Steve

&lt;/pre&gt;</description>
    <dc:creator>Steven Schveighoffer</dc:creator>
    <dc:date>2012-05-23T03:22:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88588">
    <title>Purity of some GC functions</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88588</link>
    <description>&lt;pre&gt;Hi,

https://github.com/D-Programming-Language/druntime/pull/198

Can anyone weigh in on this? I really need to know whether I'm talking 
nonsense here, or if this is the way forward.

Thanks!

&lt;/pre&gt;</description>
    <dc:creator>Alex Rønne Petersen</dc:creator>
    <dc:date>2012-05-23T01:27:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88579">
    <title>D is a dragon, or why D matters for Bioinformatics</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88579</link>
    <description>&lt;pre&gt;http://blog.thebird.nl/?p=93

http://www.reddit.com/r/programming/comments/tzpdh/d_is_a_dragon_or_why_d_matters_for_bioinformatics/

&lt;/pre&gt;</description>
    <dc:creator>Walter Bright</dc:creator>
    <dc:date>2012-05-22T20:56:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88551">
    <title>Not auto-vectorization</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88551</link>
    <description>&lt;pre&gt;On Reddit they have linked an article that shows auto 
vectorization in GCC 4.7:

http://locklessinc.com/articles/vectorize/

http://www.reddit.com/r/programming/comments/tz6ml/autovectorization_with_gcc_47/

GCC is good, it knows many tricks, it contains a lot of pattern 
matching code and other code to allow such vectorizations, and 
that C code is almost transparent &amp;amp; standard (restrict is 
standard, and I think __builtin_assume_aligned isn't too much 
hard to #define away when not available. And something like 
--fast-math is available on most compilers (despite Walter 
doesn't like it)). So it's good to optimize legacy C code too.

But this article also shows why such strategy is not usable for 
serious purposes. If small changes risk turning off such major 
optimizations, you can't rely much on them. More generally, 
writing low-level code and hoping the compiler recovers that high 
level semantics of the code is a bit ridiculous. It's way better 
to express that semantics in a more direct way, in a standard way 
that's understood by all compilers of a language (this also 
because the code shown in that article has very simple semantics).

How is the development of the D SIMD ops going? Are those efforts 
(maybe with the help of another higher level Phobos lib) going to 
avoid the silly problems shown in that article?

Bye,
bearophile

&lt;/pre&gt;</description>
    <dc:creator>bearophile</dc:creator>
    <dc:date>2012-05-22T18:52:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88549">
    <title>Who said that Node.js scales ?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88549</link>
    <description>&lt;pre&gt;Ha yes, it is on the website.

You'll find here an article about that, and how Go do much better 
because of goroutines :

http://blog.bitcartel.com/2012/05/nodejs-cpu-blocking-thing.html

I'd be very interested to know how D compare to that, for example with 
vide.d ?

&lt;/pre&gt;</description>
    <dc:creator>deadalnix</dc:creator>
    <dc:date>2012-05-22T18:47:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88536">
    <title>Let's schedule WinAPI ASCII functions for deprecation!</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88536</link>
    <description>&lt;pre&gt;Since Win9x isn't supported any more why do we have ASCII WinAPI 
functions in druntime's core.sys.windows.windows (and, possibly, other 
places)?

Reasons against *A functions:
* using of every such function is unsafe (with really seldom exceptions 
like LoadLibraryA("ntdll")) because inability to encode non-ASCII 
characters to OEM encoding will almost always give unpredictable results 
for programmer (simple test: you, reader, what will happen?);
* in D it's too easy to make a mistake by passing UTF-8 string pointer 
to such function because D has no string types other than UTF and 
elimination of such function is the only solution unless ASCII string 
type is created
* it performs worse because Windows has to convert ASCII string to 
UTF-16 first

And yes, druntime already has encoding bugs because of using such functions.

P.S.
Let's finally solve encoding problems that should be solved 10 years 
ago! By the way, Git+TurtoiseGit still has encoding problems on Windows 
and it is awful (see its changelog).

&lt;/pre&gt;</description>
    <dc:creator>Denis Shelomovskij</dc:creator>
    <dc:date>2012-05-22T18:11:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88513">
    <title>why D matters for Bioinformatics</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88513</link>
    <description>&lt;pre&gt;An interesting post and case for using D in bioinformatics by
Pjotr Prins
http://blog.thebird.nl/?p=93

&lt;/pre&gt;</description>
    <dc:creator>george</dc:creator>
    <dc:date>2012-05-22T16:01:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88499">
    <title>DCT use cases - draft</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88499</link>
    <description>&lt;pre&gt;http://d-coding.com/2012/05/22/dct-use-cases.html

&lt;/pre&gt;</description>
    <dc:creator>Roman D. Boiko</dc:creator>
    <dc:date>2012-05-22T14:04:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.d.general/88481">
    <title>Is the D community lacking development tools?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.d.general/88481</link>
    <description>&lt;pre&gt;http://d-coding.com/2012/05/22/is-the-d-community-lacking-development-tools.html

&lt;/pre&gt;</description>
    <dc:creator>Roman D. Boiko</dc:creator>
    <dc:date>2012-05-22T10:03:35</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.d.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.d.general</link>
  </textinput>
</rdf:RDF>

