On 2011-03-02 08:47, Jonathan M Davis wrote:
On Tuesday 01 March 2011 23:43:27 Jonathan M Davis wrote:
On Tuesday 01 March 2011 22:18:49 Bekenn wrote:
Code:
class MyException : Exception
{
this(string message, string file, size_t line, Throwable next =
On Tuesday 01 March 2011 23:43:27 Jonathan M Davis wrote:
> On Tuesday 01 March 2011 22:18:49 Bekenn wrote:
> > Code:
> > class MyException : Exception
> > {
> >
> > this(string message, string file, size_t line, Throwable next =
> > null)
> > {
> >
On Tuesday 01 March 2011 22:18:49 Bekenn wrote:
> Code:
>
> class MyException : Exception
> {
> this(string message, string file, size_t line, Throwable next =
> null)
> {
> super(message, file, line, next);
> }
>
>
Code:
class MyException : Exception
{
this(string message, string file, size_t line, Throwable next =
null)
{
super(message, file, line, next);
}
this(string file = __FILE__, size_t line = __LINE__)(string
On 3/1/2011 4:12 PM, bearophile wrote:
Bekenn:
I'd remove those parens; you don't want people modifying TRUE or FALSE.
Please, show me working code that implements your idea :-)
Bye,
bearophile
Here you go; I only changed the one line. Compiles and works just fine
in dmd 2.051.
On 3/1/2011 2:33 PM, bearophile wrote:
Do you know why DMD doesn't give a compilation error here?
import core.stdc.stdio: sscanf;
immutable int value = 5;
void main() {
sscanf("10".ptr, "%d".ptr,&value);
}
Bye,
bearophile
I'm not sure that's checkable. I think this falls squarely into
On 3/1/11 5:31 PM, bearophile wrote:
Bekenn:
Touche. I'll have to test that out once I get back from work...
Sorry for that answer of mine, we are here to learn and cooperate, not to fight
:-) It's just I sometimes have problems with const things in D, and sometimes
DMD has problems with c
Bekenn:
> Touche. I'll have to test that out once I get back from work...
Sorry for that answer of mine, we are here to learn and cooperate, not to fight
:-) It's just I sometimes have problems with const things in D, and sometimes
DMD has problems with const things.
Bye,
bearophile
I put together bindings for DevIL in D to use on a school assignment. The
bindings (attached) work fine on Windows, but cause a segfault on Linux when I
call ilInit.
this can be demonstrated by a little test program
"
import graphics.bindings.devil;
public void main(string[] args)
{
ilInit()
On 3/1/11 4:12 PM, bearophile wrote:
Bekenn:
I'd remove those parens; you don't want people modifying TRUE or FALSE.
Please, show me working code that implements your idea :-)
Touche. I'll have to test that out once I get back from work...
Bekenn:
> I'd remove those parens; you don't want people modifying TRUE or FALSE.
Please, show me working code that implements your idea :-)
Bye,
bearophile
On 3/1/11 3:00 PM, bearophile wrote:
const(Foo)* TRUE, FALSE;
I'd remove those parens; you don't want people modifying TRUE or FALSE.
never mind, i got it. i had to pass the switches:
-D -unittest -cov
life is hard. it's even harder when you're dumb.
I am running the dmd2 compiler on my Win7 64 bit machine and everything
appears to work except the -cov switch. i cannot seem to generate a .lst file.
any ideas?
thanks
dan mcleran
http://d.puremagic.com/issues/show_bug.cgi?id=5678
On 01/03/2011 22:52, Spacen Jasset wrote:
On 01/03/2011 16:59, d coder wrote:
> I'm afraid that I have no idea what would be "stale" about a shared
variable.
> sychronized uses a mutex, and if you want to avoid race conditions,
you need to
> use mutexes or something similar when dealing with sh
This seems to work:
import core.stdc.stdio: printf;
struct Foo {
bool b;
this(bool b_) { this.b = b_; }
}
const(Foo)* TRUE, FALSE;
static this() {
TRUE = new const(Foo)(true);
FALSE = new const(Foo)(false);
}
const(Foo)* not(const(Foo)* op) {
return (op == TRUE) ? FALSE : TRUE;
On 01/03/2011 16:59, d coder wrote:
> I'm afraid that I have no idea what would be "stale" about a shared
variable.
> sychronized uses a mutex, and if you want to avoid race conditions,
you need to
> use mutexes or something similar when dealing with shared variables.
But I don't
> know what
spir:
> It seems to be the kind of stupid issue that will make you laugh about me.
> But
> I cannot grasp and want to move forward anyway; so, let us be bold and take
> the
> risk ;-)
Be bold. Understanding things is much more important. I've being wrong hundreds
of times on D newsgroups, bu
Do you know why DMD doesn't give a compilation error here?
import core.stdc.stdio: sscanf;
immutable int value = 5;
void main() {
sscanf("10".ptr, "%d".ptr, &value);
}
Bye,
bearophile
On 28.02.2011 20:24, Denis Koroskin wrote:
On Mon, 28 Feb 2011 22:04:44 +0300, simendsjo
wrote:
On 28.02.2011 18:52, simendsjo wrote:
// ERROR
auto res = mysql_library_init(0, null, null);
auto cn = mysql_init(null);
auto oldcn = cn;
writeln(mysql_errno(cn));
assert(cn == oldcn); // when t
That worked, thanks. This is interesting because the example used in "The D
Programming Language" on page 83 gets away with it just fine. I had no problem
running this:
result ~= to!string(bitsSet(b)) ~ ", ";
On 02/28/2011 07:39 PM, Tom wrote:
> foo([[1,2],[3,4],[5,6]]); // ERROR [1]
> bar([[1,2],[3,4],[5,6]]); // OK
> foo!int([[1,2],[3,4],[5,6]]); // OK
...
> void foo(T)(T[2][] t) {
> writeln(typeid(t));
> }
>
> void bar(T)(T[][] t) {
> writeln(typeid(t));
> }
On 03/01/2011 04:30 AM, bearophile wr
Hello,
It seems to be the kind of stupid issue that will make you laugh about me. But
I cannot grasp and want to move forward anyway; so, let us be bold and take the
risk ;-)
I'm modeling a little dynamic language. Elements (values, objects) are pointers
to structs (actually tagged unions) a
> I'm afraid that I have no idea what would be "stale" about a shared
variable.
> sychronized uses a mutex, and if you want to avoid race conditions, you
need to
> use mutexes or something similar when dealing with shared variables. But I
don't
> know what would be "stale" about a variable.
>
One
On Tuesday 01 March 2011 06:40:31 d coder wrote:
> Greetings
>
> I have a doubt about synchronized code blocks.
>
> I learnt that in Java the synchronized keyword has two fold effect.
> Firstly it locks the code to make sure that only a single thread gets
> access to the code block at a given tim
On 2011-03-01 16:54, Dmitry Olshansky wrote:
On 27.02.2011 13:41, Jacob Carlborg wrote:
On 2011-02-26 19:49, Dmitry Olshansky wrote:
On 26.02.2011 19:52, Jacob Carlborg wrote:
On 2011-02-26 12:29, Dmitry Olshansky wrote:
On 26.02.2011 14:10, Jacob Carlborg wrote:
I'm trying to use the std.re
On 2011-03-01 14:03, Dmitry Olshansky wrote:
On 28.02.2011 22:37, Jacob Carlborg wrote:
The following code will result in an AssertError or RangeError when run.
import std.regex;
import std.stdio;
void main ()
{
auto m = "abc".match(`a(\w)b`);
writeln(m.hit); // AssertError in regex.d:1795
wr
On 27.02.2011 13:41, Jacob Carlborg wrote:
On 2011-02-26 19:49, Dmitry Olshansky wrote:
On 26.02.2011 19:52, Jacob Carlborg wrote:
On 2011-02-26 12:29, Dmitry Olshansky wrote:
On 26.02.2011 14:10, Jacob Carlborg wrote:
I'm trying to use the std.regex module but when I run my
application I
ge
Greetings
I have a doubt about synchronized code blocks.
I learnt that in Java the synchronized keyword has two fold effect.
Firstly it locks the code to make sure that only a single thread gets
access to the code block at a given time. Secondly, it makes sure that
the data elements accessed insi
On 28.02.2011 22:37, Jacob Carlborg wrote:
The following code will result in an AssertError or RangeError when run.
import std.regex;
import std.stdio;
void main ()
{
auto m = "abc".match(`a(\w)b`);
writeln(m.hit); // AssertError in regex.d:1795
writeln(m.captures); // RangeError i
http://d.puremagic.com/issues/show_bug.cgi?id=5671
David Nadlinger:
> Maybe I missed something as well, but to me it seems to be a CTFE bug,
> because if you split the offending line into two parts, it
>
> result ~= to!string(i);
> result ~= ", ";
>
> Please consider filing this to Bugzilla.
Wow. I was wrong, and you are right. It's not a prob
Peter Lundgren:
> I'm trying to use mixins to generate an array of numbers that are coprime to a
> statically known value. I've tried the following, but I receive the error:
>
> Error: to(i) ~ ", " cannot be interpreted at compile time
Currently to!() can't run at compile-time.
Are you sure you
On 3/1/11 11:45 AM, spir wrote:
makePossibleAValues() obviously returns a runtime value, so mixin()
cannot evaluate it, I guess.
Nope, that's not the problem due to CTFE (compile time function execution).
David
On 3/1/11 7:58 AM, Peter Lundgren wrote:
I'm trying to use mixins to generate an array of numbers that are coprime to a
statically known value. I've tried the following, but I receive the error:
Error: to(i) ~ ", " cannot be interpreted at compile time
[…]
Maybe I missed something as well, but
Ali Çehreli:
> That's because the type of literals like [1, 2] are slices (dynamic
> arrays), not fixed-sized arrays.
Then why is this accepted?
foo!int([[1,2],[3,4],[5,6]]); // OK
Bye,
bearophile
On Tue, 01 Mar 2011 07:19:21 -0500, Lars T. Kyllingstad
wrote:
On Tue, 01 Mar 2011 12:25:30 +0100, Magnus Lie Hetland wrote:
2. How can I make r.front = foo work, when I only have r.front(),
returning a ref (which seems like it is used in actual code)?
I think this is a bug, but I'm not e
On Tue, 01 Mar 2011 12:25:30 +0100, Magnus Lie Hetland wrote:
> In Andrei's book, as well as in the Phobos source, there are property
> getters that return refs, as in...
>
> @property ref T front() {
> return _payload[0];
> }
>
> ... and code that uses this with simple assignments, su
On 3/1/2011 7:18 PM, Bekenn wrote:
On 3/1/2011 12:25 AM, Tyro[a.c.edwards] wrote:
Nevertheless, execution haults
at the very next line following/catch and Create() never returns.
CreateWindow sends a few messages to your window proc; anything
interesting happening there?
Not sure how to chec
In Andrei's book, as well as in the Phobos source, there are property
getters that return refs, as in...
@property ref T front() {
return _payload[0];
}
... and code that uses this with simple assignments, such as:
r.front = foo;
For some reason, I can't get this to work in my code :-
On 03/01/2011 07:58 AM, Peter Lundgren wrote:
I'm trying to use mixins to generate an array of numbers that are coprime to a
statically known value. I've tried the following, but I receive the error:
Error: to(i) ~ ", " cannot be interpreted at compile time
string makePossibleAValues(string na
On 3/1/2011 12:25 AM, Tyro[a.c.edwards] wrote:
Nevertheless, execution haults
at the very next line following/catch and Create() never returns.
CreateWindow sends a few messages to your window proc; anything
interesting happening there?
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
> On Tue, 01 Mar 2011 02:08:48 +0300, Tyro[a.c.edwards]
> wrote:
> > == Quote from Denis Koroskin (2kor...@gmail.com)'s article
> >> On Mon, 28 Feb 2011 19:35:47 +0300, Tyro[a.c.edwards]
> >
> >> wrote:
> >> > On 2/28/2011 11:08 PM, J Cha
44 matches
Mail list logo
