Hi,
Not sure it is a bug or a misuse of scons, but on Saucy 64, with
scons --version
script: v2.3.0, 2013/03/03 09:48:35, by garyo on reepicheep
engine: v2.3.0, 2013/03/03 09:48:35, by garyo on reepicheep
and a simple SConstruct like:
import os
env = Environment(ENV = os.e
On Wednesday, 18 September 2013 at 05:28:41 UTC, Timothee Cour
wrote:
This may have been discussed before, but I'm not sure whether
this is a bug
or not. In any case it's a bit confusing.
struct Foo2{
this(T...)(T args){
assert(0);
}
}
void main(){
auto a2=Foo2();//doesn't call asser
On Wednesday, 18 September 2013 at 05:28:41 UTC, Timothee Cour
wrote:
This may have been discussed before, but I'm not sure whether
this is a bug
or not. In any case it's a bit confusing.
struct Foo2{
this(T...)(T args){
assert(0);
}
}
void main(){
auto a2=Foo2();//doesn't call asser
On Wednesday, 18 September 2013 at 04:17:41 UTC, mrd wrote:
(question is not about function body realisation - body just
don't receives right argument value)
Looks like data corruption. Can't help you much without a full
piece of code that *reproduces* the issue (reducing it helps too).
For
On Wednesday, 18 September 2013 at 08:25:02 UTC, monarch_dodra
wrote:
On Wednesday, 18 September 2013 at 04:17:41 UTC, mrd wrote:
(question is not about function body realisation - body just
don't receives right argument value)
Looks like data corruption. Can't help you much without a full
pi
On Wednesday, 18 September 2013 at 09:07:09 UTC, mrd wrote:
Looks like data corruption. Can't help you much without a full
piece of code that *reproduces* the issue (reducing it helps
too).
I will try to do it later. (I tried to copy these functions in
a separate file - the problem is not re
On Wednesday, 18 September 2013 at 09:09:29 UTC, mrd wrote:
On Wednesday, 18 September 2013 at 09:07:09 UTC, mrd wrote:
Looks like data corruption.
I can not imagine what corruption was going on here: the fact
that is contract gets the correct value, but the function itself
- not. But they
On 17/09/13 16:27, bearophile wrote:
Joseph Rushton Wakeling:
Well, I guess the best thing would be just to write here, "I license the code
under the terms of the Boost license" or something similar (public domain is
in some ways less good because not every jurisdiction recognizes it, but as
fa
On Wednesday, 18 September 2013 at 09:09:29 UTC, mrd wrote:
On Wednesday, 18 September 2013 at 09:07:09 UTC, mrd wrote:
Looks like data corruption. Can't help you much without a
full piece of code that *reproduces* the issue (reducing it
helps too).
I will try to do it later. (I tried to cop
On Wednesday, 18 September 2013 at 09:56:26 UTC, monarch_dodra
wrote:
On Wednesday, 18 September 2013 at 09:09:29 UTC, mrd wrote:
On Wednesday, 18 September 2013 at 09:07:09 UTC, mrd wrote:
Looks like data corruption. Can't help you much without a
full piece of code that *reproduces* the issue
On 18/09/13 11:55, Joseph Rushton Wakeling wrote:
On 17/09/13 16:27, bearophile wrote:
Joseph Rushton Wakeling:
Well, I guess the best thing would be just to write here, "I license the code
under the terms of the Boost license" or something similar (public domain is
in some ways less good beca
On Wednesday, 18 September 2013 at 10:37:29 UTC, mrd wrote:
Is the contract does not uses its own version of arguments?
What is the point of passing earlier changed arguments into
contract block?
That's a good question. I'll raise it on the main boards.
On Wed, Sep 18, 2013 at 10:12:04AM +0200, monarch_dodra wrote:
> On Wednesday, 18 September 2013 at 05:28:41 UTC, Timothee Cour
> wrote:
> >This may have been discussed before, but I'm not sure whether this is
> >a bug or not. In any case it's a bit confusing.
> >
> >struct Foo2{
> > this(T...)(T
Code:
const { /// [1]
int a = 3;
}
void main()
{
const { /// [2]
int b = 4;
}
}
Why is [1] allowed, but not [2]?
Namespace:
Code:
const { /// [1]
int a = 3;
}
void main()
{
const { /// [2]
int b = 4;
}
}
Why is [1] allowed, but not [2]?
Think about what this does:
void main() {
{
int b = 4;
}
}
It creates a new scope inside the functi
On Wednesday, 18 September 2013 at 07:09:27 UTC, eles wrote:
import os
env = Environment(ENV = os.environ)
gcc -o test01 -m32 test01.o -L/usr/lib -lphobos2 -lpthread -lm
Related, why the scons is passing the -L/usr/lib to the gcc,
while the LD_LIBRARY_PATH variable of my bash shell is rather
Same thing with debug:
{
// scope code
}
debug {
// debug code
}
On Wednesday, 18 September 2013 at 13:42:37 UTC, bearophile wrote:
Namespace:
Code:
const { /// [1]
int a = 3;
}
void main()
{
const { /// [2]
int b = 4;
}
}
Why is [1] allowed, but not [2]?
Think about what this does:
void main() {
{
On Wednesday, 18 September 2013 at 13:23:10 UTC, Namespace wrote:
Code:
const { /// [1]
int a = 3;
}
void main()
{
const { /// [2]
int b = 4;
}
}
Why is [1] allowed, but not [2]?
Citing grammar:
FunctionBody:
BlockStatement
BodyStatem
On Wednesday, 18 September 2013 at 14:17:04 UTC, Maxim Fomin
wrote:
On Wednesday, 18 September 2013 at 13:23:10 UTC, Namespace
wrote:
Code:
const { /// [1]
int a = 3;
}
void main()
{
const { /// [2]
int b = 4;
}
}
Why is [1] allowed, but not [2
On Wednesday, 18 September 2013 at 14:23:25 UTC, Namespace wrote:
Should I open an enhancement report?
Of course you are always free to open enhancement reports.
On Tuesday, 17 September 2013 at 11:14:10 UTC, Temtaime wrote:
I cannot use the delete/destroy. I want to call dtor at all
unreferenced objects.
Manual from Dlang size says that GC.collect triggers a full
collection. But it doesn't.
It is not possible by design as GC is not deterministic.
Des
Sorry
this is correct
http://forum.dlang.org/thread/dupcnblrqhesdvwye...@forum.dlang.org
See also
http://forum.dlang.org/thread/dupcnblrqhesdvwyeuaa@forum.dlang.orgOn
Friday, 13
On Wednesday, 18 September 2013 at 10:59:11 UTC, monarch_dodra
wrote:
On Wednesday, 18 September 2013 at 10:37:29 UTC, mrd wrote:
Is the contract does not uses its own version of arguments?
What is the point of passing earlier changed arguments into
contract block?
That's a good question. I'l
D's Array length is currently of type size_t, which means on 32
bit it's an uint and on 64 bit an ulong. This is difficult: What
if I want to give the length of an array as parameter to some C
functions which accepts only an int?
What is the right/safe way to do this? A cast? Or is there
someth
This bug reproducible also without a template:
http://pastebin.com/QPvCFYL1
$ ./bug
works:
Inside of body: value=1 type=ulong
Inside of out contract: value=1 type=ulong result=[1]
not works:
Inside of body: value=300 type=ulong
Inside of out contract: value=2 type=ulong result=[172, 2]
I'm trying to use SQLite3 in D, but am getting a segmentation fault when
I attempt to replace the exec statement with a prepare statement. What
am I doing wrong?
If the prepare statement is commented out, and the exec statement is
uncommented, the program runs successfully. (There's no data
On Wednesday, 18 September 2013 at 20:46:21 UTC, Namespace wrote:
D's Array length is currently of type size_t, which means on 32
bit it's an uint and on 64 bit an ulong. This is difficult:
What if I want to give the length of an array as parameter to
some C functions which accepts only an int?
On Wed, Sep 18, 2013 at 10:46:18PM +0200, Namespace wrote:
> D's Array length is currently of type size_t, which means on 32 bit
> it's an uint and on 64 bit an ulong. This is difficult: What if I
> want to give the length of an array as parameter to some C functions
> which accepts only an int?
>
On Wednesday, 18 September 2013 at 22:20:45 UTC, H. S. Teoh wrote:
If the C function only accepts int, then just use
to!int(array.size). If
the size overflows int, to() will throw an exception which you
can
handle. This is probably the best you can do anyway, since if
the C
function doesn't tak
In D's current status, which OS between the two would you say is
'most' supported? I'm looking at features like parallelism and
SIMD. Thanks!
On Thu, Sep 19, 2013 at 12:52:55AM +0200, Dicebot wrote:
> On Wednesday, 18 September 2013 at 22:20:45 UTC, H. S. Teoh wrote:
> >If the C function only accepts int, then just use to!int(array.size).
> >If the size overflows int, to() will throw an exception which you can
> >handle. This is probably
(new topic because old is mired in a long and clumsy source code)
import std.stdio;
static ubyte func( ulong value )
out( arr )
{
writeln( "out contract, value=", value );
}
body
{
writeln( "body, value=", value );
ubyte res;
value >>= 7;
return res;
}
void main
I just filed a bug report (
http://d.puremagic.com/issues/show_bug.cgi?id=11067)
Is there a workaround that keeps same syntax for user code?
Use case: i'm generating those from swig(+modifications to map C++
templates to D templates) so I can't factor the template bodies for
different template ins
On Wednesday, 18 September 2013 at 21:31:00 UTC, Charles Hixson
wrote:
I'm trying to use SQLite3 in D, but am getting a segmentation
fault when I attempt to replace the exec statement with a
prepare statement. What am I doing wrong?
If the prepare statement is commented out, and the exec
sta
On 2013-09-19 01:05, Jonathan A Dunlap wrote:
In D's current status, which OS between the two would you say is 'most'
supported? I'm looking at features like parallelism and SIMD. Thanks!
I don't if there are any big differences between Windows and Mac OS X in
regards those two features.
A b
On Thursday, 19 September 2013 at 01:41:15 UTC, mrd wrote:
$ ./bug
body, value=2
out contract, value=0
Why argument "value" in contract isn't equal 2 ?
Why should it be? value is a mutable argument, and the out
contract evaluates it at the return point, which is after it's
set to 0. It is
38 matches
Mail list logo
