Re: Reference to D class instance with a C library

2013-07-14 Thread Jacob Carlborg

On 2013-07-13 20:53, Leandro Motta Barros wrote:

Hey, thanks! This makes sense :-)

Am I now wondering... how safe, portable and future proof would this
be? If some future version of D implements a garbage collector capable
of moving objects around the heap, I could get in trouble, right?


Walter has always said that there's nothing in the language (D) that 
stops it from having moveable GC. In this case we would hope there would 
be way to pin objects.


--
/Jacob Carlborg


Re: Conditional Inheritance

2013-07-14 Thread lomereiter
I assume that you template ends up creating a dummy interface 
though and this isn't really acceptable.


Yes, it does. Once ':' is typed, some inheritance must occur.

Why isn't a dummy interface acceptable?


Re: Conditional Inheritance

2013-07-14 Thread Simen Kjaeraas

On 2013-07-14, 07:00, JS wrote:


I need to conditionally inherit:

interface A(T) : conditionallyInherit!(isBasicType!T, B);

A!(double) will inherit B but A!(mytype) won't.


template conditionallyInherit(bool choice, T...) {
static if (choice) {
alias conditionallyInherit = T;
} else {
import std.typetuple : TypeTuple;
alias conditionallyInherit = TypeTuple!();
}
}

Should work.

--
Simen


Re: Conditional Inheritance

2013-07-14 Thread Simen Kjaeraas

On 2013-07-14, 07:40, JS wrote:


On Sunday, 14 July 2013 at 05:30:57 UTC, lomereiter wrote:

On Sunday, 14 July 2013 at 05:04:37 UTC, JS wrote:

and while I'm at it I need to conditionally constrain types.

interface A(T) where(!isBasicType!T, (T : B));

which is suppose to require T to inherit from B if T is not basic type.


interface A(T) if (isBasicType!T || is(T : B))


Thanks, works. I remember seeing code like this somewhere but couldn't  
find any docs about it.


Here. I admit there should probably be more examples, and perhaps also
some info on the classes/interfaces/structs  unions pages.

http://dlang.org/template.html#Constraint

--
Simen


UDA's for enum values?

2013-07-14 Thread JS

I would like to do something like

enum e
{
  @(string) p,
  @(int) i
}

class a
{
   mixin(generatePropertiesFromEnum!e);
}

which would produce the result

interface a
{
@property string p();
@property int i();
}

I can generate the properties without issue but I can't seem to 
attach properties to elements in the enum. I guess this is a 
inverse-feature feature of D?





Re: UDA's for enum values?

2013-07-14 Thread JS

that should be interface a instead of class a.


Re: UDA's for enum values?

2013-07-14 Thread Dicebot

On Sunday, 14 July 2013 at 12:33:07 UTC, JS wrote:

I would like to do something like
...


Looks like a grammar issue. UDA's are supposed to be attached to 
any symbol declaration as far as I understand, which enum members 
definitely are. Probably worth bugzilla entry.




Re: Conditional Inheritance

2013-07-14 Thread Timon Gehr

On 07/14/2013 11:37 AM, lomereiter wrote:

I assume that you template ends up creating a dummy interface though
and this isn't really acceptable.


Yes, it does. Once ':' is typed, some inheritance must occur.



Nope.

template Seq(T...){ alias T Seq; }

class C : Seq!(){ }



Why isn't a dummy interface acceptable?


It creates unnecessary bloat.

template conditionallyInherit(bool inherit, T) {
static if(inherit) alias T conditionallyInherit;
else alias Seq!() conditionallyInherit;
}



Re: UDA's for enum values?

2013-07-14 Thread Maxim Fomin

On Sunday, 14 July 2013 at 13:38:41 UTC, Dicebot wrote:

On Sunday, 14 July 2013 at 12:33:07 UTC, JS wrote:

I would like to do something like
...


Looks like a grammar issue. UDA's are supposed to be attached 
to any symbol declaration as far as I understand, which enum 
members definitely are. Probably worth bugzilla entry.


Looks like http://d.puremagic.com/issues/show_bug.cgi?id=9701


Re: DLLs: Cleaning up

2013-07-14 Thread Ellery Newcomer

On 07/11/2013 05:58 AM, Chris wrote:

I have a DLL written in D I load into a Python application via ctypes
like so:

lib = CDLL(mydll)

The DLL loads and can be used no problem. However, once the DLL is
discarded of by the program, the program either doesn't react or
crashes. I still haven't worked out how to clean up the DLL correctly
before it is unloaded / detached (from Python). I guess it's the GC
and/or some C stuff I've overlooked. I have tried both approaches
described on this page: http://dlang.org/dll.html.

Maybe someone of yous once had a similar problem and found a solution.
Any hints or suggestions would be appreciated. Thanks.


hmm. pyd uses the example under 'DLLs with a C Interface' for its 
windows dll code and it seems pretty stable, but then it doesn't use 
ctypes. It doesn't look like you need to be mucking with rt_init and 
rt_term, so maybe the garbage collector is trying to collect something 
that python still has a reference to?


Also, if you can finagle a dll out of gdc I would love to hear about it. 
I have not used it on windows, though.


Re: Reference to D class instance with a C library

2013-07-14 Thread Leandro Motta Barros
The documentation of GC.addRoot() (mentioned by Simen), contains this
interesting piece of example code:

   // Also ensure that a moving collector does not relocate
   // the object.
   GC.setAttr(cast(void*)context, GC.BlkAttr.NO_MOVE);

Looks like we *already* have the way to pin objects to their current
memory location. (This compiles and is running without errors so far,
though I didn't try to look if it is actually doing something under
the hood -- which currently doesn't matter much, since the current GC
doesn't move objects).

(And yes, a GC.clrAttr() call does exist, too.)

LMB


On Sun, Jul 14, 2013 at 6:29 AM, Jacob Carlborg d...@me.com wrote:
 On 2013-07-13 20:53, Leandro Motta Barros wrote:

 Hey, thanks! This makes sense :-)

 Am I now wondering... how safe, portable and future proof would this
 be? If some future version of D implements a garbage collector capable
 of moving objects around the heap, I could get in trouble, right?


 Walter has always said that there's nothing in the language (D) that stops
 it from having moveable GC. In this case we would hope there would be way to
 pin objects.

 --
 /Jacob Carlborg


interacting with a process with redirected stdin/stdout/stderr

2013-07-14 Thread Timothee Cour
I'm trying to interact with a process using std.process and
redirected stdin/stdout/stderr.
What would be the recommended way?

For example:

auto pipes=pipeShell(myprocess,Redirect.all);
while(true){
  pipes.stdin.rawWrite(some_command);
  foreach (line; pipes.stdout.byLine) {
//do something with line
  }
}


This doesn't work because it might block inside pipes.stdout.byLine, as the
process is requesting more inputs to be written to its stdin before
outputting more bytes to its stdout.

What's the right approach?
* fcntl(fd, F_SETFL, O_NONBLOCK); didn't seem to work
* reading pipes.stdout inside a separate thread?
In that second case, how to cleanly dispose of a blocked thread when we no
longer need it?

Any detailed example would help.
Thanks!


enum inheritance

2013-07-14 Thread JS

It would be nice to be able to use enums in a hierarchical way:

enum colors
{
 enum Red { RedOrange, ... }
 enum Green { GreenBlue, ...}
 enum Blue { BlueYellow, ... }
...
}

which would be the same as the flattened version,

enum colors
{
   Red, RedOrange, ..., Green, GreenBlue, ..., Blue, BlueYellow, 
..., ...

}

but we could dereference such as

colors.Red.RedOrange,
colors.Blue,
colors.Green.GreenBlue,

(This isn't a great example but demonstrates what I would like to 
be able to do)


Is anything like this possible?



Re: enum inheritance

2013-07-14 Thread JS
BTW, the usefulness is to group sub-enums into the same range. 
This would make it easy/efficient to branch over a range in the 
enum:


if (v in colors.Red) { v is a color in red }

instead of

if (v is color.Red || v is color.RedOrange || ...)


Re: enum inheritance

2013-07-14 Thread JS

On Monday, 15 July 2013 at 04:27:42 UTC, JS wrote:
BTW, the usefulness is to group sub-enums into the same range. 
This would make it easy/efficient to branch over a range in the 
enum:


if (v in colors.Red) { v is a color in red }

instead of

if (v is color.Red || v is color.RedOrange || ...)


I guess a more intelligent structure is needed so changes in the 
enum do not break binaries. (although this is already somewhat of 
an issue with enums as changes in order requires a re-compilation)