Hi,
this module is not really well documented, they are no example to use =>
http://dlang.org/phobos/std_mmfile.html . someone could write a little
how to ?
thanks
http://en.wikipedia.org/wiki/Memory-mapped_file
hi,
I would like to know if std.stdio.File.byChunk has a double buffer as in
openGL (in other domain i know) for speed up. When you read the buffer
behind it has already start to precessing the second buffer.
thanks
It took me a while to narrow this down:
struct Foo
{
int val = int.init;
this(inout(int) nval) inout {
this.val = nval;
}
}
test.d(18): Error: cannot modify const/immutable/inout expression this.val
Is there any special reason why this should be disallowed? I mean the
same th
On 03/10/2012 11:00 PM, newcomer[bob] wrote:
On Friday, 9 March 2012 at 14:07:10 UTC, Timon Gehr wrote:
On 03/09/2012 06:50 AM, newcomer[bob] wrote:
The following is a matrix implementation of the fibonacci algorithm:
int fib(int n) { int M[2][2] = {{1,0},{0,1}} for (int i = 1; i < n;
i++) M =
On Friday, 9 March 2012 at 14:07:10 UTC, Timon Gehr wrote:
On 03/09/2012 06:50 AM, newcomer[bob] wrote:
The following is a matrix implementation of the fibonacci
algorithm:
int fib(int n) { int M[2][2] = {{1,0},{0,1}} for (int i = 1; i
< n;
i++) M = M * {{1,1},{1,0}} return M[0][0]; }
probl
Templates not overriding non-template functions is a bug
http://d.puremagic.com/issues/show_bug.cgi?id=1528
On Sat, Mar 10, 2012 at 11:09:04AM -0800, Jonathan M Davis wrote:
> On Saturday, March 10, 2012 09:04:42 H. S. Teoh wrote:
[...]
> > Hmm. The more I think about it, the more I'm leaning towards
> > simplifying contracts so that most, if not all, of any complicated
> > checks happen in an external f
On Saturday, March 10, 2012 09:04:42 H. S. Teoh wrote:
> On Sat, Mar 10, 2012 at 08:48:32AM -0800, Jonathan M Davis wrote:
> > On Saturday, March 10, 2012 16:53:42 Jacob Carlborg wrote:
> > > On 2012-03-09 18:59, H. S. Teoh wrote:
> [.[..]
>
> > > > I agree, though, that catching Errors outside of
On Saturday, March 10, 2012 15:44:26 Magnus Lie Hetland wrote:
> On 2012-03-09 18:42:01 +, Jonathan M Davis said:
> > File has a name property. You can do something like
> >
> > auto file = File.tmpfile();
> > auto filename = file.name;
> > auto str = readText(filename);
>
> Yeah -- again, so
On Saturday, March 10, 2012 17:03:43 Jacob Carlborg wrote:
> On 2012-03-09 20:06, Jonathan M Davis wrote:
> > In what way? Yes, they're _catchable_, but everything that was on the
> > unwound portion of the stack is now in an undefined state. So, recovering
> > from the AssertError and continuing e
On Sat, Mar 10, 2012 at 08:48:32AM -0800, Jonathan M Davis wrote:
> On Saturday, March 10, 2012 16:53:42 Jacob Carlborg wrote:
> > On 2012-03-09 18:59, H. S. Teoh wrote:
[.[..]
> > > I agree, though, that catching Errors outside of unittests is a
> > > very, very bad idea in general.
> >
> > I don
On Saturday, March 10, 2012 16:52:43 Jacob Carlborg wrote:
> On 2012-03-09 17:56, Jonathan M Davis wrote:
> > The current implementation may not skip them, but if so, that might
> > actually be a bug. Errors are not intended to be recoverable, so you
> > can't rely on them hitting finally blocks, s
On Saturday, March 10, 2012 16:53:42 Jacob Carlborg wrote:
> On 2012-03-09 18:59, H. S. Teoh wrote:
> > This opens up the question of, what's the *recommended* way of writing
> > unittests that check for these sorts of stuff?
> >
> > For example, I believe in being thorough in unit tests, so I lik
On 2012-03-09 20:06, Jonathan M Davis wrote:
In what way? Yes, they're _catchable_, but everything that was on the unwound
portion of the stack is now in an undefined state. So, recovering from the
AssertError and continuing execution doesn't work. So, a handler can catch the
AssertError and do
On 2012-03-09 18:59, H. S. Teoh wrote:
This opens up the question of, what's the *recommended* way of writing
unittests that check for these sorts of stuff?
For example, I believe in being thorough in unit tests, so I like to use
them to verify that the complicated in-contract I just wrote actu
On 2012-03-09 17:56, Jonathan M Davis wrote:
The current implementation may not skip them, but if so, that might actually
be a bug. Errors are not intended to be recoverable, so you can't rely on them
hitting finally blocks, scope statements, or destructors. They may very well do
so at present.
On 2012-03-09 17:56, Jonathan M Davis wrote:
It was never intended that AssertError or any other Error be particularly
catchable, but it's also true that D is a systems programming language, so
it'll let you do stuff which is unsafe, so if you know what you're doing, then
there are circumstances
On 2012-03-09 18:42:01 +, Jonathan M Davis said:
File has a name property. You can do something like
auto file = File.tmpfile();
auto filename = file.name;
auto str = readText(filename);
Yeah -- again, sorry my original post was so verbose, but part of the
"problem spec" was that my temp
On Saturday, 10 March 2012 at 03:32:44 UTC, Caligo wrote:
struct B { }
struct C { }
struct D { }
struct A {
ref A foo(B item) {
/* do something special. */
return this;
}
ref A foo(T)(T item) if(is(T == C) || is(T == D)) {
/* nothing sp
You can strip
> ref A foo(T)(T item) if (is(T==B)) {
down to:
ref A foo(T : B)(T item) // or to match your example
ref A foo(T == B)(T item)
On 03/10/2012 04:32 AM, Caligo wrote:
struct B { }
struct C { }
struct D { }
struct A {
ref A foo(B item) {
/* do something special. */
return this;
}
ref A foo(T)(T item) if(is(T == C) || is(T == D)) {
/* nothing special, do
On 3/9/12, Timon Gehr wrote:
> On 03/09/2012 07:08 PM, Andrej Mitrovic wrote:
>> Yeah I understood it as a general concept as well. Probably many
>> people did. Why doesn't Andrei chime in?
>
> I think he does not read the D.learn newsgroup.
>
Ah poo. This is like East Berlin in here. :P
22 matches
Mail list logo
