Re: Catching signals with D
On 12/22/11 23:51 , Matej Nanut wrote:
Hello everyone, I've been fascinated by D lately and have been using it
for all
my school assignments (like simple ray casting and simulated annealing).
What I can't find anywhere is how to do something like
"signal(SIGINT, myhandler)" (I'm in a Linux environment).
I need this to stop the annealing process early but still keep the
current best
result. Is there a better way to interrupt my program?
Thanks!
Matej
P.s. I hope I sent this to the appropriate address. :)
Hi!
I don't know of any official way, but since D links against the c
runtime you can just hook up functions from there, I believe. This works
on osx at least:
import std.stdio;
extern(C) void signal(int sig, void function(int) );
// Our handler, callable by C
extern(C) void handle(int sig){
writeln("Signal:",sig);
}
void main()
{
enum SIGINT = 2; // OS-specific
signal(SIGINT,&handle);
writeln("Hello!");
readln();
writeln("End!");
}
$ rdmd sig.d
Hello!
^CSignal:2
^CSignal:2
End!
$ _
/HF
Catching signals with D
Hello everyone, I've been fascinated by D lately and have been using it for all my school assignments (like simple ray casting and simulated annealing). What I can't find anywhere is how to do something like "signal(SIGINT, myhandler)" (I'm in a Linux environment). I need this to stop the annealing process early but still keep the current best result. Is there a better way to interrupt my program? Thanks! Matej P.s. I hope I sent this to the appropriate address. :)
Re: ctfe bug?
Jacob Carlborg wrote:
> On 2011-12-22 14:39, Timon Gehr wrote:
>> On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
>>> On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing
to an
array and there are no out-of-bounds reads. Still, the following code
fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = "8ab3060e2cba4f23b74cb52db3bdfb46";
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by
making
ragel use array indexing instead of pointers, but that'd be a
performance
issue for runtime code as well.
>>>
>>> Why would arrays be slower than pointers? You do know that you can turn
>>> off array bounds checking?
>>>
>>
>> Yes but the length has to be stored and updated, therefore for example
>> p++ is less machine instructions/memory accesses/register pressure than
>> arr = arr[1..$].
>
> Ok, I see. Then this seems to be a very performance critical piece of
> code.
>
In this special case it's not that important (simple UUID parser), but ragel
is also used for HTTP parsers in webservers (lighttpd2), json parsers, etc
and it's main advantage is speed.
Re: test if object is instance of class at compile time
On Thu, Dec 22, 2011 at 8:35 AM, Trass3r wrote: > I'd really like to have 'if (instance is ClassType)' syntax in D. It couldn't use that syntax because 'is' means direct bitwise equality everywhere else. Changing it in this one situation would be awkward.
Re: newbie question: can D do this?
On Thu, Dec 22, 2011 at 16:45, clk wrote: > Philippe, > I don't understand the example below to simulate the list comprehension > syntax. Are input1, input2 and input3 ranges? Yes, inputs are ranges. Sorry, I was perhaps a bit hasty in answering. The code is on github: https://github.com/PhilippeSigaud/dranges comp() is defined into the algorithm.d module. Github does not host the docs, but I generated them on dsource a long time ago: http://svn.dsource.org/projects/dranges/trunk/dranges/docs/algorithm.html (search for comp, there is no anchor. I think there wasn't a way to make them easily on DDoc a year ago)
Re: test if object is instance of class at compile time
I'd really like to have 'if (instance is ClassType)' syntax in D.
Re: newbie question: Can D do this?
On Thu, Dec 22, 2011 at 16:37, clk wrote: > Philippe, > Thank you very much for your response. It looks similar to what I've done > in javascript by wrapping all function arguments into a single object > literal but the D alternative you propose is a little to convoluted for a > beginner like me. Perhaps I'll understand it better after I'm done reading > the D book. Oh yes, it *is* convoluted :) What I was proposing is to try and code it myself, if others find the resulting syntax acceptable. I wouldn't know, since I do not use named arguments myself.
Re: test if object is instance of class at compile time
Timon Gehr wrote:
> On 12/21/2011 09:15 PM, Elvis Maehren wrote:
[...]
>> Moreover, in CTFE a failed cast terminates the interpretation ("cannot
>> reinterpret class from [...] to [...] at compile time").
>
> I don't think this is filed already. Maybe you want to file a bug report?
ok, did that: http://d.puremagic.com/issues/show_bug.cgi?id=7154
[...]
> use traits(__compiles, {...}), where '...' is the exact code that fails.
> But that is a mere workaround. What you are doing should/will work.
Vladimir Panteleev pointed me to __traits(compiles, ...), too. I think that
doesn't work out:
Elvis Maehren wrote:
> Vladimir Panteleev wrote:
>> I believe that's what __traits(compiles, ...) is for:
>
> __traits(compiles, cast(T) o) is true even if the cast blows up in CTFE,
> so that doesn't work.
Or am I missing something?
Re: newbie question: can D do this?
Philippe,
I don't understand the example below to simulate the list comprehension
syntax. Are input1, input2 and input3 ranges? Where is the comp
function defined?
Thank you,
-clk
(Christian Keppenne)
auto lc = comp!("tuple(a,b,c)", "a*a+b*b == c*c&& a
--
Message: 2
Date: Tue, 20 Dec 2011 21:45:26 +0100
From: Philippe Sigaud
To: "digitalmars.D.learn"
Subject: Re: newbie question: Can D do this?
Message-ID:
Content-Type: text/plain; charset=UTF-8
On Mon, Dec 19, 2011 at 17:17, clk wrote:
Correct. As other have said, it's doable by combining std functions.
As fas as I know, we do not have a cartesian product range, to iterate
on all combinations of two or more ranges.
[f(x,y) for x in list1 for y in list2 if condition]
I gave it a try a few years ago and could get something like this:
auto lc = comp!("tuple(a,b,c)", "a*a+b*b == c*c&& amapper, condition,
input ranges, as many as you wish
But at the time I couldn't find a way to do bindings, that is:
[f(x,y) for x in [0..10] for y in [0..x]]
-> the range iterated by y depends on x.
If anyone has an idea, I'm game.
Philippe
Re: newbie question: Can D do this?
Philippe,
Thank you very much for your response. It looks similar to what I've
done in javascript by wrapping all function arguments into a single
object literal but the D alternative you propose is a little to
convoluted for a beginner like me. Perhaps I'll understand it better
after I'm done reading the D book.
To bad D doesn't support passing arguments by name. It makes code so
much easier to read, especially in large projects. Even Fortran allows it.
-clk
(Christian Keppenne)
On 20/12/2011 14:18, clk wrote:
I remember a discussion about year ago or so.
It seems doable to have some kind of function transformer (adaptor?) for this.
from:
int foo(int a = 0, int b = 1, double c = 0.0, bool d = false) { return 1;}
alias namedParams!foo nfoo; // transform it into a called-by-name function.
nfoo(["d": true]); // a = 0, b = 1, c = 0.0, d = true
nfoo(["d" : true], ["b" : 100]); // a=0, b=100, c=0.0, d=true
nfoo(1, 2, ["d" : true]); // a=1, b=2, c=0.0, d=true
That is, it expects some values, then string/values couples as
associative arrays.
Would that be palatable? Because I think it's doable.
To obtain the arguments names:
int foo(int a, int b, double c = 0.0, bool d = true) { return 1;}
template Name(alias foo) if (isCallable!foo)
{
enum string Name = S!(foo.stringof);
}
template S(string s) // this template is just a trick because
foo.stringof directly displeases DMD
{
enum string S = s;
}
writeln(Name!foo); // "int(int a, int b, double c = 0, bool d = true)"
So this gives us:
- the arguments names
- which ones have default values
- what is that default value
The difficulty here is correctly parsing the ( ,,,) part, without
getting desoriented by argument types that themselves use (,), like
templated types.
I think that would make for an small& interesting community challenge.
Philippe
End of Digitalmars-d-learn Digest, Vol 71, Issue 34
***
Re: ctfe bug?
On 2011-12-22 14:39, Timon Gehr wrote:
On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing
to an
array and there are no out-of-bounds reads. Still, the following code
fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = "8ab3060e2cba4f23b74cb52db3bdfb46";
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by
making
ragel use array indexing instead of pointers, but that'd be a
performance
issue for runtime code as well.
Why would arrays be slower than pointers? You do know that you can turn
off array bounds checking?
Yes but the length has to be stored and updated, therefore for example
p++ is less machine instructions/memory accesses/register pressure than
arr = arr[1..$].
Ok, I see. Then this seems to be a very performance critical piece of code.
--
/Jacob Carlborg
Re: ctfe bug?
On 12/22/2011 10:28 AM, Jacob Carlborg wrote:
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing
to an
array and there are no out-of-bounds reads. Still, the following code
fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = "8ab3060e2cba4f23b74cb52db3bdfb46";
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by making
ragel use array indexing instead of pointers, but that'd be a performance
issue for runtime code as well.
Why would arrays be slower than pointers? You do know that you can turn
off array bounds checking?
Yes but the length has to be stored and updated, therefore for example
p++ is less machine instructions/memory accesses/register pressure than
arr = arr[1..$].
Re: test if object is instance of class at compile time
On 12/21/2011 09:15 PM, Elvis Maehren wrote:
This works fine at runtime, but explodes in CTFE:
---
bool isInstanceOf(T, O)(O o) {
return (cast(T) o) !is null;
}
---
CTFE doesn't like "!is null" ("cannot compare [...] at compile time").
This will be fixed in the next release:
http://d.puremagic.com/issues/show_bug.cgi?id=7143
Moreover, in CTFE a failed cast terminates the interpretation ("cannot
reinterpret class from [...] to [...] at compile time").
I don't think this is filed already. Maybe you want to file a bug report?
Is this somehow
catchable? If so, I could do something along these lines:
---
if(__ctfe) {
try {
auto t = cast(T) o;
return true;
} catch {
return false;
}
}
---
use traits(__compiles, {...}), where '...' is the exact code that fails.
But that is a mere workaround. What you are doing should/will work.
onStartTag for root node in std.xml
In the test code, the onStartTag will not be called for the root node "set".
The onEndTag is OK, and the onStartTag is OK for sub nodes.
Is this a bug, or just it is? Can anybody confirm it?
Thanks.
// test.d
module main;
import std.string;
import std.stdio;
import std.xml;
int main(string[] argv)
{
string s = r"
A
B
";
string tempStr;
auto xml = new DocumentParser(s);
xml.onStartTag["set"] = (ElementParser xml)
{
tempStr = "start=>" ~ xml.tag.name;
writefln(tempStr);
xml.parse();
};
xml.onEndTag["set"] = (in Element e)
{
tempStr = "end=>" ~ e.tag.name;
writefln(tempStr);
};
xml.parse();
return 0;
}
Re: ctfe bug?
Jacob Carlborg wrote:
> On 2011-12-22 08:47, Johannes Pfau wrote:
>> Hi,
>> the following code is reduced from a parser generated with Ragel
>> (http://www.complang.org/ragel/). That's also the reason why it's
>> using pointers instead of array access, but Ragel guarantees that there
>> won't be any out-of-bound reads.
>>
>> AFAIK pointers are supported in CTFE now as long as they're pointing to
>> an array and there are no out-of-bounds reads. Still, the following code
>> fails:
>>
>>
>> ubyte[4] testCTFE()
>> {
>> ubyte[4] data;
>> string input = "8ab3060e2cba4f23b74cb52db3bdfb46";
>> auto p = input.ptr;
>> p++; p++;
>> data[0] = parse!ubyte((p-2)[0 .. 2], 16);
>> p++; p++;
>> data[1] = parse!ubyte((p-2)[0 .. 2], 16);
>> p++; p++;
>> data[2] = parse!ubyte((p-2)[0 .. 2], 16);
>> p++; p++;
>> data[3] = parse!ubyte((p-2)[0 .. 2], 16);
>> p++; p++;
>> return data;
>> }
>> enum ctfe = testCTFE();
>>
>> void main()
>> {
>> import std.stdio;
>> writeln(testCTFE()); //[138, 179, 6, 14]
>> writeln(ctfe); //[138, 138, 138, 138]
>> }
>>
>>
>> Has this bug already been filed? I could possibly circumvent it by making
>> ragel use array indexing instead of pointers, but that'd be a performance
>> issue for runtime code as well.
>
> Why would arrays be slower than pointers? You do know that you can turn
> off array bounds checking?
>
Don't know, but I remember some benchmarks showed that arrays were slower,
even with bounds-checking off. (I think that was brought up in some
discussion about the tango xml parser).
Also the default for ragel is to use pointers, so I'd like to use that.
Making it use arrays means extra work ;-)
And turning off bounds-checking is not a perfect solution, as it applies to
the complete module. As I said, ragel makes sure that the pointer access is
safe, so there's really no issue in using pointers.
Re: test if object is instance of class at compile time
Jacob Carlborg wrote:
> On 2011-12-21 21:15, Elvis Maehren wrote:
>> This works fine at runtime, but explodes in CTFE:
>> ---
>> bool isInstanceOf(T, O)(O o) {
>> return (cast(T) o) !is null;
>> }
>> ---
>>
[...]
> I don't think you can do a test like that during compile time. In your
> above function, isInstanceOf, "o" will always be of the type "O". You
> can always do a comparisons to see if O is the same type as T.
>
I don't think testing for equality of O and T gets me anywhere. T is usually
derived from O. That makes it a different type, but still o may be castable
to T.
Re: test if object is instance of class at compile time
Vladimir Panteleev wrote: > I believe that's what __traits(compiles, ...) is for: __traits(compiles, cast(T) o) is true even if the cast blows up in CTFE, so that doesn't work.
Re: ctfe bug?
On 2011-12-22 08:47, Johannes Pfau wrote:
Hi,
the following code is reduced from a parser generated with Ragel
(http://www.complang.org/ragel/). That's also the reason why it's
using pointers instead of array access, but Ragel guarantees that there
won't be any out-of-bound reads.
AFAIK pointers are supported in CTFE now as long as they're pointing to an
array and there are no out-of-bounds reads. Still, the following code fails:
ubyte[4] testCTFE()
{
ubyte[4] data;
string input = "8ab3060e2cba4f23b74cb52db3bdfb46";
auto p = input.ptr;
p++; p++;
data[0] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[1] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[2] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
data[3] = parse!ubyte((p-2)[0 .. 2], 16);
p++; p++;
return data;
}
enum ctfe = testCTFE();
void main()
{
import std.stdio;
writeln(testCTFE()); //[138, 179, 6, 14]
writeln(ctfe); //[138, 138, 138, 138]
}
Has this bug already been filed? I could possibly circumvent it by making
ragel use array indexing instead of pointers, but that'd be a performance
issue for runtime code as well.
Why would arrays be slower than pointers? You do know that you can turn
off array bounds checking?
--
/Jacob Carlborg
Re: writing iterators without code duplication. inout?
On Thu, Dec 22, 2011 at 12:04 AM, pompei2 wrote:
>> int delegate(int delegate(ref int)) doIter() const
>> {
>> 74 return (int delegate(ref int) dg)
>> {
>> cast(typeof(this))(this).doIter()
>> 77 (
>> 78 (ref int i)
>>
>> {
>> int copy = i; dg(copy);
>> }
>> );
>> }
>> }
>
>
> I see what you are doing there. Unfortunately, the innermost delegate (the
> one doing the copy trick) somehow got @system attribute, which leads to the
> following compile errors (I added line numbers and reordered your code in
> the citation above):
>
> constiter.d(78): Error: cannot implicitly convert expression (__dgliteral2)
> of type void delegate(ref int i) @system to int delegate(ref int)
> constiter.d(77): Error: cast has no effect in expression
> (cast(const(Container))this.doIter()((__error)))
> constiter.d(74): Error: cannot implicitly convert expression (__dgliteral1)
> of type void delegate(int delegate(ref int) dg) @system to int delegate(int
> delegate(ref int))
>
> Where does this @system come from? How do I get rid of it?
Actually, it looks like your issue is here:
constiter.d(78): Error: cannot implicitly convert expression
(__dgliteral2) of type *void* delegate(ref int i) @system to int
delegate(ref int)
void delegate(ref int) != int delegate(ref int)
Re: writing iterators without code duplication. inout?
int delegate(int delegate(ref int)) doIter() const
{
74 return (int delegate(ref int) dg)
{
cast(typeof(this))(this).doIter()
77(
78 (ref int i)
{
int copy = i; dg(copy);
}
);
}
}
I see what you are doing there. Unfortunately, the innermost
delegate (the one doing the copy trick) somehow got @system
attribute, which leads to the following compile errors (I added
line numbers and reordered your code in the citation above):
constiter.d(78): Error: cannot implicitly convert expression
(__dgliteral2) of type void delegate(ref int i) @system to int
delegate(ref int)
constiter.d(77): Error: cast has no effect in expression
(cast(const(Container))this.doIter()((__error)))
constiter.d(74): Error: cannot implicitly convert expression
(__dgliteral1) of type void delegate(int delegate(ref int) dg)
@system to int delegate(int delegate(ref int))
Where does this @system come from? How do I get rid of it?
Until
int delegate(ref inout int) opApply() inout;
and
int delegate(int delegate(ref inout int)) doIter() inout;
are made to work. (I actually don't know if there is any
obstacles to do this).
Can you point me to the bugreport so I can vote for it? I'm not
sure if it is #4838 or if they are unrelated.
Re: ctfe bug?
Johannes Pfau wrote: > > Has this bug already been filed? I could possibly circumvent it by making > ragel use array indexing instead of pointers, but that'd be a performance > issue for runtime code as well. OK, I found a workaround: If I use data[x] = parse!ubyte(input[p-input.ptr-2 .. p-input.ptr], 16); instead, it works. So the issue is related to pointer slicing in ctfe.
