Re: Starting with D
On 6/02/11 11:35 PM, Julius wrote: Hi there, i'm all new to D but not new to programming in general. I'd like to try D but i didn't find a nice tutorial yet. I don't want to read a whole book, I just want to get the basics so I can start. Can you help me find something like that? Best regards, Julius What languages do you know already? If it's one of C++, C#, or Java, you might just be able to jump right in, and just reference the website every now and then for specifics.
Re: Setting thread priority
Am 06.02.2011 02:58, schrieb Peter Alexander: How do you set the priority of a thread, or otherwise control how much CPU time it gets? depends on operating system - on windows: set the priority to high does not help if your system isn't under pressure ...
Re: higher-order funcs for ranges (with usual interface)
On Thu, 03 Feb 2011 19:11:04 +0100, spir wrote:
On 02/03/2011 02:25 PM, Lars T. Kyllingstad wrote:
On Thu, 03 Feb 2011 13:53:44 +0100, spir wrote:
On 02/03/2011 01:17 PM, Lars T. Kyllingstad wrote:
Why the reluctance to use template constraints? They're so flexible!
:)
I cannot stand the is() idiom/syntax ;-) Dunno why. Would happily
get rid of it in favor of type-classes (built eg as an extension to
current interfaces). For instance, instead of:
void func (T) (T t)
if (is(someConstraint1) is(someConstraint2))
{
...
}
use:
void func (SomeTypeClass T) (T t)
{
...
}
For instance (untested):
void func (T) (T t)
if (isInputRange(T) is(ElementType!T == E))
--
void func (InputRange!E T) (T t)
where InputRange is a (templated) interface / type-class.
Type-class checks on /type/ /template/ parameters (as opposed to type
checks on regular value parameters) would be performed structurally
(as opposed to nominally). D knows how to do this, since that's what
it needs to perform when checking is() constraints.
I agree that is() is rather ugly. Same with __traits. If you haven't
already done so, I suggest you vote up this issue:
http://d.puremagic.com/issues/show_bug.cgi?id=3702
Done!
(I did not get all the details 'cause no time for a deep look, but
anything impulsed by the motivation of getting rid of is() and __traits
can hardly be a Bad Thing ;-)
What do you think of type classes, as an alternative to Don's proposal
in issue #3702.
See also Type Classes as Objects and Implicits:
http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf
Anyway, you can hide is()'s ugliness in the most common cases, though,
by defining new templates. For instance, I wouldn't mind having the
following in std.range as an overload of isInputRange:
template isInputRange(R, T)
{
enum isInputRange = isInputRange!R is(ElementType!R == T);
}
Then, you'd simply write
void func(R)(R range) if (isInputRange!(R, E)) { ... }
-Lars
A great improvement, indeed.
While we're at defining a set of constraints in a template, let us make
it an interface / type-class that the E must (structurally) satisfy, and
just write:
void func(InputRange!E R)(R range) { ... }
What do you think?
Note: a template is not always required, I guess:
void writeElements (Iterable Elements) (Elements elements) {
foreach (element, elements) {
write(element,' ');
}
}
(In this case, because write is itself generic.)
How would you deal with the case where the input must satisfy more than
one concept/constraint? I mean, for the simple case where you say R
must be an input range of E, sure, type classes/concepts are cleaner.
But what about the case where, say, you want R to be an infinite random
access range that supports slicing? With template constraints it's
simple:
void doStuff(R)(R someRange)
if (isRandomAccessRange!R isInfinite!R hasSlicing!R)
{
...
}
Now, I'm no expert on concepts at all---my main sources of information
about them are superficial comments on the D newsgroup and a quick browse
of the Wikipedia page---but it seems to me that you'd have to define a
new concept for each such combination of constraints. Or?
-Lars
Re: higher-order funcs for ranges (with usual interface)
On 02/07/2011 09:18 AM, Lars T. Kyllingstad wrote:
I cannot stand the is() idiom/syntax ;-) Dunno why. Would happily
get rid of it in favor of type-classes (built eg as an extension to
current interfaces). For instance, instead of:
void func (T) (T t)
if (is(someConstraint1) is(someConstraint2))
{
...
}
use:
void func (SomeTypeClass T) (T t)
{
...
}
For instance (untested):
void func (T) (T t)
if (isInputRange(T) is(ElementType!T == E))
--
void func (InputRange!E T) (T t)
where InputRange is a (templated) interface / type-class.
Type-class checks on/type/ /template/ parameters (as opposed to type
checks on regular value parameters) would be performed structurally
(as opposed to nominally). D knows how to do this, since that's what
it needs to perform when checking is() constraints.
I agree that is() is rather ugly. Same with __traits. If you haven't
already done so, I suggest you vote up this issue:
http://d.puremagic.com/issues/show_bug.cgi?id=3702
Done!
(I did not get all the details 'cause no time for a deep look, but
anything impulsed by the motivation of getting rid of is() and __traits
can hardly be a Bad Thing ;-)
What do you think of type classes, as an alternative to Don's proposal
in issue #3702.
See also Type Classes as Objects and Implicits:
http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf
Anyway, you can hide is()'s ugliness in the most common cases, though,
by defining new templates. For instance, I wouldn't mind having the
following in std.range as an overload of isInputRange:
template isInputRange(R, T)
{
enum isInputRange = isInputRange!R is(ElementType!R == T);
}
Then, you'd simply write
void func(R)(R range) if (isInputRange!(R, E)) { ... }
-Lars
A great improvement, indeed.
While we're at defining a set of constraints in a template, let us make
it an interface / type-class that the E must (structurally) satisfy, and
just write:
void func(InputRange!E R)(R range) { ... }
What do you think?
Note: a template is not always required, I guess:
void writeElements (Iterable Elements) (Elements elements) {
foreach (element, elements) {
write(element,' ');
}
}
(In this case, because write is itself generic.)
How would you deal with the case where the input must satisfy more than
one concept/constraint? I mean, for the simple case where you say R
must be an input range of E, sure, type classes/concepts are cleaner.
But what about the case where, say, you want R to be an infinite random
access range that supports slicing? With template constraints it's
simple:
void doStuff(R)(R someRange)
if (isRandomAccessRange!R isInfinite!R hasSlicing!R)
{
...
}
Now, I'm no expert on concepts at all---my main sources of information
about them are superficial comments on the D newsgroup and a quick browse
of the Wikipedia page---but it seems to me that you'd have to define a
new concept for each such combination of constraints. Or?
Well, dunno really. If a language implements type classes, let us see how
things work there :-)
Note that above, you use 3 implicite type-class defining check funcs. Agreed?
Certainly, because they are common, one wrote a fucn to wrap a bigger set of
is() stuff. Replacing them with a type-class interface allows
(1) reusing an interface for what it's meant: defining a (super) type, instead
of a func which is appropriate and does /not/ correctly convey the meaning
(2) avoiding is()
Now, you may be right in that type-class check may need be written externally:
void doStuff(R)(R someRange)
if (RandomAccessRange R InfiniteRange R Slicable R)
or not:
interface ASpecialOne : RandomAccessRange, InfiniteRange, Slicable {}
void doStuff (ASpecialOneR) (R someRange)
Ain't that clean? For sure, if I was to define a new static PL, I would go
/that/ way for generic constraints.
This remembers me about another option maybe: when I have time, I'll go and see
how XL does it. If (you do not know XL, then /really/ have a look when you have
time: http://en.wikipedia.org/wiki/XL_%28programming_language%29 ;esp explore
the notion of conceptual programming)
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Using D libs in C
On 02/07/2011 07:53 AM, GreatEmerald wrote: Hmm, no, it won't work right on Linux for some reason. This is the output: /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o): In function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable': src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x4): undefined reference to `_deh_beg' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc): undefined reference to `_deh_beg' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13): undefined reference to `_deh_end' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x37): undefined reference to `_deh_end' collect2: ld returned 1 exit status --- errorlevel 1 The shell script I'm using to compile it is: #!/bin/sh dmd -m32 -c -lib dpart.d gcc -m32 -c cpart.c dmd -m32 cpart.o dpart.a /usr/lib/libphobos2.a (Although it appears that you don't need to explicitly link with libphobos2, it does it automatically... and fails with the above error.) Any ideas about what the error means? Take my words with much doubt, I've few exp in that. Are you sure you did use same source under both OSes? undefined reference to `_deh_end' / `_deh_beg' (read: D-begin / D-end I guess, looks like Pascal slang ;-) is nicely output by the linker when your main module does not have a main(). (There is a similar error when an imported module has a main(), eg for testing, so that the linker finds 2 of them.) Did you change something before compiling under Linux? Or does this pseudo-error happen only under Linux? Add an empty main() to your top module, and tell us... Denis -- _ vita es estrany spir.wikidot.com
Re: Using D libs in C
On 2011-02-07 07:32, GreatEmerald wrote: All right, found out how to make it compile. There are two ways: 1) Using DMD for the D part, DMC for the C part and combining them. This is the batch file I use for that: dmd -c -lib dpart.d dmc cpart.c dpart.lib phobos.lib 2) Using DMD for the D part, DMC for the C part, DMD for combining them again: dmd -c -lib dpart.d dmc -c cpart.c dmd cpart.obj dpart.lib phobos.lib The first method gives me a FIXLIB warning but compiles OK, the second is nicely silent, thus I prefer the second one. Plus it should work in Linux as well. I'm going to try that shortly. I would recommend always linking with dmd, then you want need to link any D specifics, like phobos. -- /Jacob Carlborg
Re: Starting with D
== Quote from Peter Alexander (peter.alexander...@gmail.com)'s article On 6/02/11 11:35 PM, Julius wrote: Hi there, i'm all new to D but not new to programming in general. I'd like to try D but i didn't find a nice tutorial yet. I don't want to read a whole book, I just want to get the basics so I can start. Can you help me find something like that? Best regards, Julius What languages do you know already? If it's one of C++, C#, or Java, you might just be able to jump right in, and just reference the website every now and then for specifics. I know Java yet. Can you point me to the parts of the website where i should look? I'm somehow unable to find the right site. Thank you.
Re: Using D libs in C
Everything is right from what I can tell. This is the code I use for the D part:
module dpart;
import std.c.stdio;
extern(C):
shared int ResultD;
int Process(int Value)
{
printf(You have sent the value: %d\n, Value);
ResultD = (Value % 5);
return ResultD;
}
And the C part:
#include stdio.h
extern int ResultD;
int Process(int Value);
int main()
{
printf(Sending 3...\n);
Process(3);
printf(The result is %d\n, ResultD);
getchar();
return 0;
}
This is pretty much the same thing as in the Windows version, just with scanf()
omitted.
Jacob, in Windows I am required to explicitly tell DMD to compile phobos.lib,
but
not in Linux. Quite odd.
Re: Debugging D?
On 06/02/11 22:28, Sean Eskapp wrote: == Quote from Robert Clipsham (rob...@octarineparrot.com)'s article On 06/02/11 20:29, Sean Eskapp wrote: Are debug symbols compiled with -gc stored in a separate file? Visual Studio refuses to debug my things, and windbg seems to be remarkably unhelpful. I suggest you take a look at VisualD if you're using visual studio, it will handle converting debug info so that visual studio can understand it, and give you some intellisense. http://www.dsource.org/projects/visuald I'm using VisualD already, but the project is configured using Makefiles, and I don't want to go through the hassle of changing project configs in two locations. Is there any way to still get Visual Studio debugging information if it's a makefile project? As Trass3r said, you can run the object file through cv2pdb - I've never used this though so I can't tell you how to use it. Take a look at http://dsource.org/projects/cv2pdb for more information, I guess you just need to add another command to your make file. -- Robert http://octarineparrot.com/
Re: Using D libs in C
On Mon, 07 Feb 2011 06:42:46 -0500, spir denis.s...@gmail.com wrote: On 02/07/2011 07:53 AM, GreatEmerald wrote: Hmm, no, it won't work right on Linux for some reason. This is the output: /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o): In function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable': src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x4): undefined reference to `_deh_beg' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc): undefined reference to `_deh_beg' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13): undefined reference to `_deh_end' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x37): undefined reference to `_deh_end' collect2: ld returned 1 exit status --- errorlevel 1 The shell script I'm using to compile it is: #!/bin/sh dmd -m32 -c -lib dpart.d gcc -m32 -c cpart.c dmd -m32 cpart.o dpart.a /usr/lib/libphobos2.a (Although it appears that you don't need to explicitly link with libphobos2, it does it automatically... and fails with the above error.) Any ideas about what the error means? Take my words with much doubt, I've few exp in that. Are you sure you did use same source under both OSes? undefined reference to `_deh_end' / `_deh_beg' deh == d exception handling (or handler, not sure) ;) Looks like the module that's failing to link is rt.deh -Steve
Re: Using D libs in C
On 2/7/11, GreatEmerald past...@gmail.com wrote: in Windows I am required to explicitly tell DMD to compile phobos.lib, but not in Linux. Quite odd. Check the sc.ini file in dmd/windows/bin, make sure it has at least this for the LIB variable: LIB=%@P%\..\lib;
Re: Using D libs in C
On Mon, 07 Feb 2011 10:28:41 -0500, GreatEmerald past...@gmail.com wrote:
Everything is right from what I can tell. This is the code I use for the
D part:
module dpart;
import std.c.stdio;
extern(C):
shared int ResultD;
int Process(int Value)
{
printf(You have sent the value: %d\n, Value);
ResultD = (Value % 5);
return ResultD;
}
And the C part:
#include stdio.h
extern int ResultD;
int Process(int Value);
int main()
{
printf(Sending 3...\n);
Process(3);
printf(The result is %d\n, ResultD);
getchar();
return 0;
}
This is pretty much the same thing as in the Windows version, just with
scanf()
omitted.
Jacob, in Windows I am required to explicitly tell DMD to compile
phobos.lib, but
not in Linux. Quite odd.
The issue is that you are not calling the D runtime initialization code.
This is required in order to get D working properly. See the C main
function in druntime here:
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L335
Basically, you are going to have to duplicate the runtime startup code.
I'm not sure it will work properly. People typically run main from D and
call their C functions from there. This is also certainly an option.
The errors you are getting are link errors. I'm guessing that maybe
because you aren't calling the d runtime, the linker is opimizing out the
deh code early on, but then needs it again later? Not sure.
-Steve
Re: Starting with D
On 2011-02-07 15:20, Julius wrote: == Quote from Peter Alexander (peter.alexander...@gmail.com)'s article On 6/02/11 11:35 PM, Julius wrote: Hi there, i'm all new to D but not new to programming in general. I'd like to try D but i didn't find a nice tutorial yet. I don't want to read a whole book, I just want to get the basics so I can start. Can you help me find something like that? Best regards, Julius What languages do you know already? If it's one of C++, C#, or Java, you might just be able to jump right in, and just reference the website every now and then for specifics. I know Java yet. Can you point me to the parts of the website where i should look? I'm somehow unable to find the right site. Thank you. Language: http://www.digitalmars.com/d/2.0/lex.html Standard library: http://www.digitalmars.com/d/2.0/phobos/phobos.html -- /Jacob Carlborg
Re: Using D libs in C
OK, well this is interesting... I managed to compile it but it's quite odd. In order to do that, I added a call to main() in my Process() function, and then added an empty main() in the D part before extern(C). It seems that there are no conflicts, too. Andrej, that line is there. But it really doesn't matter, it's not like adding one word to the command line is hard.
Re: Starting with D
Julius Wrote: Hi there, i'm all new to D but not new to programming in general. I'd like to try D but i didn't find a nice tutorial yet. I don't want to read a whole book, I just want to get the basics so I can start. Can you help me find something like that? Best regards, Julius Well there is the Starting with D page on Wiki4D http://www.wikiservice.at/d/wiki.cgi?D__Tutorial/StartingWithD And also a related page for those comping from another language http://www.wikiservice.at/d/wiki.cgi?ComingFrom Any improvement to these pages as you learn D are welcome.
Re: Why non-@property functions don't need parentheses
It will be fixed at some point, but it hasn't been yet. Oh cool, all right; thanks!
Re: higher-order funcs for ranges (with usual interface)
If you want to use an interface as a concept, you can take kenji's
adaptTo module and add this:
template conformsTo(T, Interfaces...)
{
enum conformsTo = AdaptTo!Interfaces.hasRequiredMethods!T;
}
and use it like this
void draw(T)(T shape) if (conformsTo!(T, Shape, Drawable))
This will of course only work for methods, not properties or aliases,
so you still need constraints in some cases.
Torarin
Re: Using D libs in C
On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
On Mon, 07 Feb 2011 06:42:46 -0500, spir denis.s...@gmail.com wrote:
On 02/07/2011 07:53 AM, GreatEmerald wrote:
Hmm, no, it won't work right on Linux for some reason. This is the output:
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o): In
function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x37):
undefined reference to `_deh_end'
collect2: ld returned 1 exit status
--- errorlevel 1
The shell script I'm using to compile it is:
#!/bin/sh
dmd -m32 -c -lib dpart.d
gcc -m32 -c cpart.c
dmd -m32 cpart.o dpart.a /usr/lib/libphobos2.a
(Although it appears that you don't need to explicitly link with libphobos2, it
does it automatically... and fails with the above error.) Any ideas about
what the
error means?
Take my words with much doubt, I've few exp in that.
Are you sure you did use same source under both OSes?
undefined reference to `_deh_end' / `_deh_beg'
deh == d exception handling (or handler, not sure) ;)
Looks like the module that's failing to link is rt.deh
Are you sure of that? I get exactly the same kind of linker error when
forgetting a fake main(){} (whatver the number of modules). Eg:
...
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13):
undefined reference to `_deh_end'
...
repeted n times.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: higher-order funcs for ranges (with usual interface)
On 02/07/2011 01:07 PM, Torarin wrote:
If you want to use an interface as a concept, you can take kenji's
adaptTo module and add this:
template conformsTo(T, Interfaces...)
{
enum conformsTo = AdaptTo!Interfaces.hasRequiredMethods!T;
}
and use it like this
void draw(T)(T shape) if (conformsTo!(T, Shape, Drawable))
This will of course only work for methods, not properties or aliases,
so you still need constraints in some cases.
That's nice, thank you.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Using D libs in C
On Mon, 07 Feb 2011 13:53:14 -0500, spir denis.s...@gmail.com wrote:
On 02/07/2011 04:32 PM, Steven Schveighoffer wrote:
On Mon, 07 Feb 2011 06:42:46 -0500, spir denis.s...@gmail.com wrote:
On 02/07/2011 07:53 AM, GreatEmerald wrote:
Hmm, no, it won't work right on Linux for some reason. This is the
output:
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o):
In
function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x37):
undefined reference to `_deh_end'
collect2: ld returned 1 exit status
--- errorlevel 1
The shell script I'm using to compile it is:
#!/bin/sh
dmd -m32 -c -lib dpart.d
gcc -m32 -c cpart.c
dmd -m32 cpart.o dpart.a /usr/lib/libphobos2.a
(Although it appears that you don't need to explicitly link with
libphobos2, it
does it automatically... and fails with the above error.) Any ideas
about
what the
error means?
Take my words with much doubt, I've few exp in that.
Are you sure you did use same source under both OSes?
undefined reference to `_deh_end' / `_deh_beg'
deh == d exception handling (or handler, not sure) ;)
Looks like the module that's failing to link is rt.deh
Are you sure of that? I get exactly the same kind of linker error when
forgetting a fake main(){} (whatver the number of modules). Eg:
...
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13):
undefined reference to `_deh_end'
...
repeted n times.
Hm... it looks like _deh_beg and _deh_end is something defined by the
compiler? It's used in deh2.d but not defined anywhere in druntime.
I'm pretty sure deh stands for d exception handler.
-Steve
Re: std.concurrency immutable classes...
Michel Fortin napisał: I just made this pull request today: https://github.com/D-Programming-Language/dmd/pull/ If you want to test it, you're very welcome. Here is my development branch for this feature: https://github.com/michelf/dmd/tree/const-object-ref Thanks for doing this. Is it approved by Walter? -- Tomek
Re: std.concurrency immutable classes...
On 2011-02-07 17:11:08 -0500, Tomek Sowiński j...@ask.me said: Michel Fortin napisał: I just made this pull request today: https://github.com/D-Programming-Language/dmd/pull/ If you want to test it, you're very welcome. Here is my development branch for this feature: https://github.com/michelf/dmd/tree/const-object-ref Thanks for doing this. Is it approved by Walter? Depends on what you mean by approved. He commented once on the newsgroup after I posted an earlier version of the patch, saying I should add tests for type deduction and some other stuff. This change his something he attempted to do in the past and failed, I expect him to be skeptical. I guess he'll review it when he has the time and I hope he'll merge these changes in the mainline. He'll probably want to take his time however, since it can break existing code in some cases; it's basically a change to the language. If you want to show your support, I guess you can vote up the enhancement request in the bugzilla. http://d.puremagic.com/issues/show_bug.cgi?id=5325 Also feel free to compile it, test it, and share your experience. The more tested it is, the more used and appreciated it is, the more exposure it gets, the sooner it gets approved, or so I guess. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
