Re: Squaring Arrays without Overlapping Array Error
On 7/7/15 12:45 PM, jmh530 wrote: On Tuesday, 7 July 2015 at 13:58:17 UTC, Steven Schveighoffer wrote: Yeah, this seems like an unnecessary limitation for exact matching. In other words, if your destination array exactly matches one or more of the arguments, it should be fine. Where the overlapping starts causing problems is something like this: x[1..$] *= x[0..$-1]; I would love to see this limitation fixed. Do you think I should file a bug report? Sure, file as an enhancement. -Steve
Re: Squaring Arrays without Overlapping Array Error
On Tuesday, 7 July 2015 at 13:58:17 UTC, Steven Schveighoffer wrote: Yeah, this seems like an unnecessary limitation for exact matching. In other words, if your destination array exactly matches one or more of the arguments, it should be fine. Where the overlapping starts causing problems is something like this: x[1..$] *= x[0..$-1]; I would love to see this limitation fixed. -Steve Do you think I should file a bug report?
Re: Correctly implementing a bidirectional range on a linked list?
On Tuesday, 7 July 2015 at 09:35:12 UTC, Jonathan M Davis wrote: This is why you almost never use @trusted on templated functions. You should _never_ mark anything with @trusted unless you can guarantee that it's actually @safe. @safe is inferred for templated functions, so unless you're doing @system operations in a templated function, there is no need for @trusted, and if you are doing @system operations, then they need to be segregated in a way that you can mark that section of code as @trusted and guarantee that it's @safe regardless of what the template argument is. But you should _never_ mark code as @trusted if it involves calling functions that you can't guarantee are @safe, which almost always means that you should not mark code which calls functions on template arguments as @trusted. That being said, @trusted is very much a necessity in certain types of code, so it would be really bad if we didn't have it. But if you're marking much code as @trusted, or if you're marking templated code as @trusted, then you really need to be examining what you're doing. Very little code should need to be marked as @trusted, and every time that it is, you need to be able to absolutely guarantee that it's actually @safe in spite of the @system operations that you're doing in that code. - Jonathan M Davis Thanks for the advice.
Re: Squaring Arrays without Overlapping Array Error
On Tuesday, 7 July 2015 at 05:27:10 UTC, jmh530 wrote:
If I call a function like
int[] square_array(int[] x)
{
return x[] *= x[];
}
I get an error that there is an overlapping array in a vector
operation. I guess this makes sense as the lhs and rhs are
occupying the same memory. Nevertheless, I find it a little
frustrating.
I tried two alternatives, one just adds a temporary duplicate
array for the lhs x[] in the above, while the other uses a
foreach loop. Both get correct results without errors, but also
have their issues. Duplicating requires memory allocation,
which makes it slower for small arrays. Foreach (ignoring
parallelism or SIMD) tends to be slower for larger arrays, I
take it due to compiler optimizations for vector operations.
Are there any other alternatives here?
I have never used arrays in that way before, though I don't get
why you are writing return line in that way. Shouldn't it be like
`return (x[] * x[]);` ?
Re: FFMPEG Bindings
On Tuesday, 7 July 2015 at 03:05:11 UTC, ketmar wrote: How stable has the FFMPEG API since beginning 2015? don't know, but various players stop bundling ffmpeg long time ago. i assume that API is stable enough to stop worrying about it. Ok, thanks.
Re: Squaring Arrays without Overlapping Array Error
On Tuesday, 7 July 2015 at 08:06:50 UTC, tcak wrote: On Tuesday, 7 July 2015 at 05:27:10 UTC, jmh530 wrote: [...] I have never used arrays in that way before, though I don't get why you are writing return line in that way. Shouldn't it be like `return (x[] * x[]);` ? But, yes, the result should be stored somewhere still. Since either you, or the compiler would be writing a loop for multiplication already, I would be writing by hand for this operation.
Re: Understanding Safety of Function Pointers vs. Addresses of Functions
On Tuesday, 7 July 2015 at 19:54:19 UTC, jmh530 wrote:
I'm not sure I understand the safety of function pointers vs.
the addresses of functions. The code below illustrates the
issue.
I was under the impression that pointers are not allowed in
safe code.
No, pointers are fine. It's pointer arithmetic that's considered
unsafe.
Naturally, I took that to also mean that function pointers are
not allowed in safe code. Indeed, I haven't been able to pass a
function pointer to a safe function. However, I am able to take
the address of a function and pass that as a parameter. It
seems to work fine for taking the address of functions and
templates (so long as I !)
So long as you exclamation mark? Huh?
import std.stdio : writeln;
import std.traits;
import std.math;
void function_safety(T)(T fp)
{
if (functionAttributes!fp FunctionAttribute.safe)
writeln(fp is safe);
else if (functionAttributes!fp FunctionAttribute.trusted)
writeln(fp is trusted);
else if (functionAttributes!fp FunctionAttribute.system)
writeln(fp is system);
else
writeln(fp is neither safe nor trusted nor system);
}
void main()
{
function_safety(cbrt); //prints fp is trusted
real function(real) fp = cbrt;
You're explicitly typing that as `real function(real)` which is
not an @safe type. Add @safe and you're good to go:
real function(real) @safe fp = cbrt;
function_safety(fp); /* prints fp is safe */
Or let the compiler infer things:
auto fp = cbrt;
function_safety(fp); /* prints fp is trusted */
function_safety(fp); //prints fp is system
}
Understanding Safety of Function Pointers vs. Addresses of Functions
I'm not sure I understand the safety of function pointers vs. the
addresses of functions. The code below illustrates the issue.
I was under the impression that pointers are not allowed in safe
code. Naturally, I took that to also mean that function pointers
are not allowed in safe code. Indeed, I haven't been able to pass
a function pointer to a safe function. However, I am able to take
the address of a function and pass that as a parameter. It seems
to work fine for taking the address of functions and templates
(so long as I !)
import std.stdio : writeln;
import std.traits;
import std.math;
void function_safety(T)(T fp)
{
if (functionAttributes!fp FunctionAttribute.safe)
writeln(fp is safe);
else if (functionAttributes!fp FunctionAttribute.trusted)
writeln(fp is trusted);
else if (functionAttributes!fp FunctionAttribute.system)
writeln(fp is system);
else
writeln(fp is neither safe nor trusted nor system);
}
void main()
{
function_safety(cbrt); //prints fp is trusted
real function(real) fp = cbrt;
function_safety(fp); //prints fp is system
}
One other related issue. The code above works for some parts of
std.math, but it doesn't for all of it. I thought it was that
some of them are defined in other places, so I used static import
and tried
function_safety(std.math.cos);
but I'm still getting this error (other people seem to have an
issue with linking and getting it, but I'm not making any other
change and shouldn't need to link anything).
OPTLINK (R) for Win32 Release 8.00.17
Copyright (C) Digital Mars 1989-2013 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
[path]\AppData\Local\Temp\.rdmd\rdmd-testing_fp_template_purity.d-A5DD
C99AC50E1539BAB8627648C9740B\objs\testing_fp_template_purity.exe.obj(testing_fp_
template_purity.exe)
Error 42: Symbol Undefined _D3std4math3cosFNaNbNiNfeZe
--- errorlevel 1
Re: Squaring Arrays without Overlapping Array Error
On Tuesday, 7 July 2015 at 17:05:21 UTC, Steven Schveighoffer wrote: Sure, file as an enhancement. -Steve https://issues.dlang.org/show_bug.cgi?id=14783
Re: Understanding Safety of Function Pointers vs. Addresses of Functions
On Tue, Jul 07, 2015 at 07:54:18PM +, jmh530 via Digitalmars-d-learn wrote:
I'm not sure I understand the safety of function pointers vs. the addresses
of functions. The code below illustrates the issue.
Function pointers and addresses of functions are the same thing. There
is no difference between them.
I was under the impression that pointers are not allowed in safe code.
This is incorrect. Pointers are allowed in safe code as long as they are
not manipulated in unsafe ways (e.g., assigning a literal value to them,
pointer arithmetic, casting to a pointer to an incompatible type, using
a pointer to call an un-@safe function from @safe code, etc.).
Naturally, I took that to also mean that function pointers are not
allowed in safe code. Indeed, I haven't been able to pass a function
pointer to a safe function. However, I am able to take the address of
a function and pass that as a parameter. It seems to work fine for
taking the address of functions and templates (so long as I !)
The reason for this is that function pointers have attributes associated
with them, as part of the type system. The address of a @safe function
is a @safe function pointer, meaning that it's legal to call the
function through this pointer in @safe code. The address of a @system
function is a @system function pointer, which *cannot* be used to call
the function from @safe code.
However, while it is not allowed to assign a @system function pointer to
a @safe function pointer (since that could be used to bypass the @safe
restriction on calling @system functions), it is OK to assign a @safe
function pointer to a @system function pointer (this is called
covariance). This is allowed because a @system function pointer can only
be dereferenced in @system code, and @system code can freely call any
function with no restrictions. Where this might become a problem,
though, is when you inadvertently assign a @safe function pointer to a
@system function pointer, and then attempt to call it from @safe code --
the compiler will reject that. This is what happened with your sample
code:
[...]
void main()
{
function_safety(cbrt); //prints fp is trusted
real function(real) fp = cbrt;
Here, fp is a @system function pointer. While cbrt is a @safe function
pointer, it is covariant with a @system function pointer, so the
assignment is allowed.
function_safety(fp); //prints fp is system
[...]
The result, however, is now @system, so you can no longer call cbrt from
@safe code through this particular function pointer (though you can
obviously call it through a @safe function pointer).
The correct syntax for declaring a @safe function pointer would be:
real function(real) @safe fp = ...;
Either that, or use `auto` to let the compiler figure out the correct
function pointer attributes for you:
auto fp = cbrt;
pragma(msg, typeof(fp).stringof);
The compiler prints:
real function(real x) nothrow @nogc @trusted
So you see here that two other attributes, nothrow and @nogc, are also
inferred by the compiler, which is a good thing because otherwise your
function pointer wouldn't be usable from nothrow or @nogc code,
respectively.
T
--
Music critic: That's an imitation fugue!
Re: Understanding Safety of Function Pointers vs. Addresses of Functions
On Tuesday, 7 July 2015 at 20:13:08 UTC, anonymous wrote: So long as you exclamation mark? Huh? Thanks for the detailed answer. All I meant here is that if I have some T foo(T)(T x), then to take the address, sometimes I've needed to foo!int or foo!real, etc.
Re: Understanding Safety of Function Pointers vs. Addresses of Functions
On Tuesday, 7 July 2015 at 20:32:49 UTC, jmh530 wrote: Thanks for the detailed answer. All I meant here is that if I have some T foo(T)(T x), then to take the address, sometimes I've needed to foo!int or foo!real, etc. Ah, sure. Templates don't have addresses. Function templates are not exempt from that. I think you always have to instantiate them in order take an address, not just sometimes.
Re: Understanding Safety of Function Pointers vs. Addresses of Functions
On Tuesday, 7 July 2015 at 20:23:08 UTC, H. S. Teoh wrote: The reason for this is that function pointers have attributes associated with them, as part of the type system. The address of a @safe function is a @safe function pointer, meaning that it's legal to call the function through this pointer in @safe code. The address of a @system function is a @system function pointer, which *cannot* be used to call the function from @safe code. However, while it is not allowed to assign a @system function pointer to a @safe function pointer (since that could be used to bypass the @safe restriction on calling @system functions), it is OK to assign a @safe function pointer to a @system function pointer (this is called covariance). This is allowed because a @system function pointer can only be dereferenced in @system code, and @system code can freely call any function with no restrictions. Where this might become a problem, though, is when you inadvertently assign a @safe function pointer to a @system function pointer, and then attempt to call it from @safe code -- the compiler will reject that. This is what happened with your sample code: This, and the rest, does such a good job explaining why I have been so confused. Either that, or use `auto` to let the compiler figure out the correct function pointer attributes for you: auto fp = cbrt; pragma(msg, typeof(fp).stringof); I've tried using auto, but I get errors when I use auto with a function that has been overloaded. For instance, creal function(creal) pure nothrow @nogc @safe fp = conj; compiles, but auto fp = conj; does not.
Re: bigint compile time errors
On Sunday, 5 July 2015 at 20:35:03 UTC, Kai Nacke wrote: On Friday, 3 July 2015 at 04:08:32 UTC, Paul D Anderson wrote: On Friday, 3 July 2015 at 03:57:57 UTC, Anon wrote: On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote: [...] Should be plusTwo(in BigInt n) instead. Yes, I had aliased BigInt to bigint. And I checked and it compiles for me too with Windows m64. That makes it seem more like a bug than a feature. I'll open a bug report. Paul The point here is that x86 uses an assembler-optimized implementation (std.internal.math.biguintx86) and every other cpu architecture (including x64) uses a D version (std.internal.math.biguintnoasm). Because of the inline assembler, the x86 version is not CTFE-enabled. Regards, Kai Could we add a version or some other flag that would allow the use of .biguintnoasm with the x86? Paul
Wrapping a C-style Array (Pointer + Length) in a Range Interface
I'm currently developing a high-level wrapper for FFMPEG at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d My question now becomes how to most easily wrap the iteration over streams at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L150 https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L152 in a nice D-style range interface. Do I have to allocate a new D array and copy the `AVStream*` elements into that or is there a convenience wrapper for constructing a lazy range from a C style Array-pointer plus array-length? Note that the elements of the C array are pointers to structs, in this case instances of `AVStream`. This, of course, complicates the matter with regard to GC-safety. Comments on that please :)
Re: Wrapping a C-style Array (Pointer + Length) in a Range Interface
On 8/07/2015 12:26 a.m., Per =?UTF-8?B?Tm9yZGzDtnci?= per.nord...@gmail.com wrote: I'm currently developing a high-level wrapper for FFMPEG at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d My question now becomes how to most easily wrap the iteration over streams at https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L150 https://github.com/nordlow/justd/blob/master/tests/t_ffmpeg.d#L152 in a nice D-style range interface. Do I have to allocate a new D array and copy the `AVStream*` elements into that or is there a convenience wrapper for constructing a lazy range from a C style Array-pointer plus array-length? Note that the elements of the C array are pointers to structs, in this case instances of `AVStream`. This, of course, complicates the matter with regard to GC-safety. Comments on that please :) size_t count; AVStream* thePtr; AVStream[] array = thePtr[0 .. count]; That should work.
Re: Which XMM are safe to erase in asm{} blocks?
On Monday, 6 July 2015 at 08:54:48 UTC, ponce wrote:
What registers can I safely modify in asm {} blocks? Especially
XMM registers.
I can't find the information on http://dlang.org/iasm.html
Note that this question isn't for function-call boundaries but
asm{} boundaries since I do not use naked;
Bump.
Is this secret knowledge?
Re: Wrapping a C-style Array (Pointer + Length) in a Range Interface
On Tuesday, 7 July 2015 at 12:29:04 UTC, Rikki Cattermole wrote: size_t count; AVStream* thePtr; AVStream[] array = thePtr[0 .. count]; That should work. Thanks. Will that reuse the existing allocate memory at `thePtr` for internal storage of the D array? If so how is the GC aware of this memory? Is there any tutorials, reference documentation, etc on these matters?
Re: Wrapping a C-style Array (Pointer + Length) in a Range Interface
On Tuesday, 7 July 2015 at 12:33:23 UTC, Per Nordlöw wrote: On Tuesday, 7 July 2015 at 12:29:04 UTC, Rikki Cattermole wrote: size_t count; AVStream* thePtr; AVStream[] array = thePtr[0 .. count]; That should work. Thanks. Will that reuse the existing allocate memory at `thePtr` for internal storage of the D array? If so how is the GC aware of this memory? Is there any tutorials, reference documentation, etc on these matters? To my knowledge it should reuse the memory and not inform the GC about it. It basically makes D treat that pointer like a slice. If you need to confirm that it is doing that, just @nogc it. If it allocates it'll fail. I'm not aware of much docs regarding these sort of tricks. But I believe it was Adam who originally discovered this little trick. Atleast I'm pretty sure he is how I learnt about it. On D.learn as well.
Re: Array operations with array of structs
On Monday, 6 July 2015 at 15:48:28 UTC, anonymous wrote:
Ok, I disabled everything in the struct except what I posted and
it ran.
I then uncommented stuff to isolate the cause. I've added in the
bits that cause the error below (plus some constructors just for
reference).
struct Vector3 {
public double[3] _p;
@nogc this(in double[] p)
{
switch ( p.length ) {
case 0: _p[0] = _p[1] = _p[2] = 0.0; break;
case 1: _p[0] = p[0]; _p[1] = _p[2] = 0.0; break;
case 2: _p[0] = p[0]; _p[1] = p[1]; _p[2] = 0.0; break;
default: _p[0] = p[0]; _p[1] = p[1]; _p[2] = p[2]; break;
}
}
@nogc this(in double p0, in double p1=0.0, in double p2=0.0)
{
_p[0] = p0;
_p[1] = p1;
_p[2] = p2;
}
@nogc this(in Vector3 other)
{
_p[] = other._p[];
}
//...
Vector3 opBinary(string op)(in Vector3 rhs) const
if (op == +){
Vector3 result;
result._p[] = this._p[] + rhs._p[];
return result;
}
// The bits that cause the error:
//... Enabling any one (or more) of the following causes the
error
this(this)
{
_p = _p.dup;
}
@nogc ref Vector3 opAssign(ref Vector3 rhs)
{
_p[] = rhs._p[];
return this;
}
@nogc ref Vector3 opAssign(Vector3 rhs)
{
_p[] = rhs._p[];
return this;
}
//...
}
Any ideas about what's happening?
Re: Correctly implementing a bidirectional range on a linked list?
On Monday, July 06, 2015 21:58:30 anonymous via Digitalmars-d-learn wrote: Off topic: I think `@trusted:` is horrible. It's easy to forget that you're in a @trusted environment when editing things later. And even worse, you're trusting everything that's passed through template parameters. This is why you almost never use @trusted on templated functions. You should _never_ mark anything with @trusted unless you can guarantee that it's actually @safe. @safe is inferred for templated functions, so unless you're doing @system operations in a templated function, there is no need for @trusted, and if you are doing @system operations, then they need to be segregated in a way that you can mark that section of code as @trusted and guarantee that it's @safe regardless of what the template argument is. But you should _never_ mark code as @trusted if it involves calling functions that you can't guarantee are @safe, which almost always means that you should not mark code which calls functions on template arguments as @trusted. That being said, @trusted is very much a necessity in certain types of code, so it would be really bad if we didn't have it. But if you're marking much code as @trusted, or if you're marking templated code as @trusted, then you really need to be examining what you're doing. Very little code should need to be marked as @trusted, and every time that it is, you need to be able to absolutely guarantee that it's actually @safe in spite of the @system operations that you're doing in that code. - Jonathan M Davis
Re: Wrapping a C-style Array (Pointer + Length) in a Range Interface
On Tuesday, 7 July 2015 at 12:36:11 UTC, Rikki Cattermole wrote: If you need to confirm that it is doing that, just @nogc it. If it allocates it'll fail. I could tag it as @nogc. Thx.
Re: Squaring Arrays without Overlapping Array Error
On 7/7/15 1:27 AM, jmh530 wrote:
If I call a function like
int[] square_array(int[] x)
{
return x[] *= x[];
}
I get an error that there is an overlapping array in a vector operation.
Yeah, this seems like an unnecessary limitation for exact matching. In
other words, if your destination array exactly matches one or more of
the arguments, it should be fine. Where the overlapping starts causing
problems is something like this:
x[1..$] *= x[0..$-1];
I would love to see this limitation fixed.
-Steve
Re: Wrapping a C-style Array (Pointer + Length) in a Range Interface
On Tuesday, 7 July 2015 at 12:33:23 UTC, Per Nordlöw wrote: On Tuesday, 7 July 2015 at 12:29:04 UTC, Rikki Cattermole wrote: size_t count; AVStream* thePtr; AVStream[] array = thePtr[0 .. count]; That should work. Thanks. Will that reuse the existing allocate memory at `thePtr` for internal storage of the D array? If so how is the GC aware of this memory? Is there any tutorials, reference documentation, etc on these matters? Slicing never* allocates a new array. The GC is only aware of memory it allocates itself and memory it is explicitly told about (see core.memory) Slicing pointers etc. should all be covered in http://dlang.org/arrays.html, http://dlang.org/d-array-article.html, http://ddili.org/ders/d.en/arrays.html and http://ddili.org/ders/d.en/slices.html *unless you're using operator overloading, in which case it can do anything of course
Re: Squaring Arrays without Overlapping Array Error
On Tuesday, 7 July 2015 at 08:06:50 UTC, tcak wrote:
I have never used arrays in that way before, though I don't get
why you are writing return line in that way. Shouldn't it be
like `return (x[] * x[]);` ?
There's nothing fundamentally wrong with doing that in the return
line. For instance, the one I duplicated the array on looks like
int[] square_array_dup(int[] x)
{
auto y = x.dup;
return y[] *= x[];
}
To get your way to work requires
int[] square_array(int[] x)
{
int[] y;
y.length = x.length;
y[] = x[] * x[];
return y;
}
which can be slower.
Anyway, the main reason I used x[] *= x[] was that the original
code I had written was not in a function and was just
void main()
{
int len = 10;
auto x = len.iota.array;
x[] *= x[];
}
Obviously, in this case, I can just do a map before putting it
into an array, but then I got more interested in squaring arrays.
Re: Coercing ranges to the same type
On Monday, 6 July 2015 at 19:46:51 UTC, Matt Kline wrote:
Say I'm trying to expand an array of file and directory paths
(such as ones given as command line args) into a range of file
paths I can iterate over. A simplified example might be:
auto getEntries(string[] paths, bool recursive)
{
auto files = paths.filter!(p = p.isFile);
if (recursive) {
auto expandedDirs = paths
.filter!(p = p.isDir)
.map!(p = dirEntries(p, SpanMode.depth, false))
.joiner
.map!(de = de.name); // back to strings
return chain(files, expandedDirs);
}
else {
return files;
}
}
Even though both return statements return a range of strings,
this doesn't compile because the result of `chain` is a
different type than the result of `filter`. Is there some
generic range I could coerce both ranges to in order to have
the same return type and make this work? .array is a
non-starter since it throws out the ranges' laziness.
I'd say, try to move 'recurse' into a compile time variable, if
you need it runtime, move it up a layer:
import std.file;
import std.range;
import std.algorithm;
void main(string[] args) {
import std.stdio;
auto recurse = true;
if(recurse)
args.getFiles.chain(recurseForFiles(args[])).writeln;
else
args.getFiles.writeln;
}
auto getFiles(string[] paths)
{
return paths.filter!(p = p.isFile);
}
auto recurseForFiles(string[] paths) {
return paths
.filter!(p = p.isDir)
.map!(p = dirEntries(p, SpanMode.depth, false))
.joiner
.filter!(p = p.isFile)
.map!(de = de.name); // back to strings
}
Re: Understanding Safety of Function Pointers vs. Addresses of Functions
I'm still not sure why I'm getting the error I mention in the
original post. For instance, the code below is giving that Error
42 Symbol Undefined error. Seems very mystifying...
import std.math : cos;
real foo(T)(T fp, real x)
{
return fp(x);
}
void main()
{
real x = 0;
real y = foo(cos, x);
}
Re: Wrapping a C-style Array (Pointer + Length) in a Range Interface
On Tue, 07 Jul 2015 12:36:09 +, Rikki Cattermole wrote: I'm not aware of much docs regarding these sort of tricks. But I believe it was Adam who originally discovered this little trick. Atleast I'm pretty sure he is how I learnt about it. On D.learn as well. i bet this trick was planned from the moment of introduction of slices in D. yet there is something that makes it dangerous: user is free to change .length of the slice wrapper. and as GC doesn't manage the memory slite is pointing to, it will copy slice contents. the program definitely will not crash, but if copied data had some pointers to that copied data (sometimes C program does this)... besides, one cannot use .ptr to `free ()` memory anymore. so while there is nothing wrong in creating slices from pointers, programmer should be aware of some potential pitfalls. signature.asc Description: PGP signature
Re: Which XMM are safe to erase in asm{} blocks?
On Tue, 07 Jul 2015 12:33:38 +, ponce wrote: Is this secret knowledge? yes. ;-) i believe that there are not so many people doing asm in D, and many of them using write and forget technique (i.e. write and don't touch if it works). so you need someone with good knowledge of backend to answer this question, and such people are rare here. ;-) so i thing that your best bet is to investigate that by yourself, and write an article about it. signature.asc Description: PGP signature
