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 envir
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 anneali
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
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.
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/Philip
I'd really like to have 'if (instance is ClassType)' syntax in D.
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.
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:
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
--
Messa
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 don
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 a
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
w
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
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[] a
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 a
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 funct
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.
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
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)
>>
>> {
>> i
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 w
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
21 matches
Mail list logo
