Re: Phobos Members-Tuple function?
On 01/20/2013 06:59 AM, Timon Gehr wrote: The somewhat related fact that static foreach over a sequence of enum values does not work is a compiler bug. I guess this is your problem. (The original post was confusing because it contained pseudo code.) To prevent confusion in the future, please always post the full code snippet.
Re: Phobos Members-Tuple function?
On 01/20/2013 04:55 AM, F i L wrote:
Ali Çehreli wrote:
The following program produces this output:
[...code...]
Awesome! Thanks, I wasn't expecting it to actually be as easy as that. I
tried all sort of difference combinations with __traits(allMembers, ..)
but it looks like I just needed to move it into the foreach loop itself.
I wounder why there's a difference when assigning to an enum...
foreach over an enum constant is not magically unrolled statically like
foreach over a sequence ("TypeTuple") is.
(The somewhat related fact that static foreach over a sequence of enum
values does not work is a compiler bug.)
Re: Phobos Members-Tuple function?
Ali Çehreli wrote: The following program produces this output: [...code...] Awesome! Thanks, I wasn't expecting it to actually be as easy as that. I tried all sort of difference combinations with __traits(allMembers, ..) but it looks like I just needed to move it into the foreach loop itself. I wounder why there's a difference when assigning to an enum...
Re: Phobos Members-Tuple function?
On 01/20/2013 03:41 AM, Ali Çehreli wrote:
...
void main()
{
auto ship = new Ship;
alias T = typeof(ship);
foreach (m; __traits(allMembers, T))
{
writefln("member %s", m);
enum atrs = __traits(getAttributes, mixin(T.stringof ~ "." ~ m));
This only works because Ship happens to be defined in the same module.
Use __traits(getMember, T, m) instead of the mixin.
foreach (a; atrs)
{
writefln(" attribute %s", a);
if (is(typeof(a) == Bind))
Engine.bindActors(ship, a.pattern);
}
}
}
Ali
Re: Phobos Members-Tuple function?
On 01/20/2013 03:59 AM, Ali Çehreli wrote:
On 01/19/2013 06:41 PM, Ali Çehreli wrote:
> class Engine
> {
> static bindActors(Actor, string pattern)
> {
> writefln(" Binding actor with pattern %s", pattern);
> }
> }
How come that function compiles without a return type? The following is
a bug, right?
class C
{
static foo() // <-- no return type; void is assumed
{}
}
void main()
{
static assert(is(typeof(C.foo()) == void));
}
Ali
Not a bug. This is function return type deduction. If you return
something from foo, then the return type will change. What is often
missed is that 'auto' does not mean anything. It exists just to make the
parser happy.
Re: Phobos Members-Tuple function?
On 01/19/2013 06:41 PM, Ali Çehreli wrote:
> class Engine
> {
> static bindActors(Actor, string pattern)
> {
> writefln(" Binding actor with pattern %s", pattern);
> }
> }
How come that function compiles without a return type? The following is
a bug, right?
class C
{
static foo() // <-- no return type; void is assumed
{}
}
void main()
{
static assert(is(typeof(C.foo()) == void));
}
Ali
Re: Phobos Members-Tuple function?
On 01/19/2013 12:10 PM, F i L wrote:
> Is there a function in phobos which will return a Tuple of a Type's
> members, for use in a foreach statement?
The following program produces this output:
member update
attribute Bind("Stage.update")
Binding actor with pattern Stage.update
member draw
attribute Bind("Canvas.draw")
Binding actor with pattern Canvas.draw
member toString
member toHash
member opCmp
member opEquals
member Monitor
member factory
I had to use a mixin and had to move __traits(allMembers) into the
foreach loop. It was necessary so that 'm' could be evaluated at compile
time. I can kind of see why but one would expect your 'enum mbrs' to
work as well.
import std.stdio;
interface Actor
{}
struct Bind
{
string pattern;
}
class Ship : Actor
{
@Bind("Stage.update") void update()
{
// ...
}
@Bind("Canvas.draw") void draw()
{
// ...
}
}
class Engine
{
static bindActors(Actor, string pattern)
{
writefln("Binding actor with pattern %s", pattern);
}
}
void main()
{
auto ship = new Ship;
alias T = typeof(ship);
foreach (m; __traits(allMembers, T))
{
writefln("member %s", m);
enum atrs = __traits(getAttributes, mixin(T.stringof ~ "." ~ m));
foreach (a; atrs)
{
writefln(" attribute %s", a);
if (is(typeof(a) == Bind))
Engine.bindActors(ship, a.pattern);
}
}
}
Ali
Re: Assembly - 64-bit registers supported?
On Saturday, 19 January 2013 at 12:45:06 UTC, deed wrote:
void main()
{
asm
{
movRAX, 3;
}
}
results in:
Error: undefined identifier 'RAX'
AX and EAX work.
Anything missing or isn't it yet implemented?
Hmm. I know there's a one byte 'escape code' that for x86 allows
you to force it to a higher/lower level, perhaps that was just
the 16/32 bit code and won't work for 64bit (different escape
code?). I think it was 0x66, so you might get away 'db'
prepending that, but I wouldn't rely on it. Sides there's lots of
little intricacies of the instruction set; like you could have a
one byte assignment to any register; That's assuming they aren't
taking them away in the 64bit versions of x86.
So...
asm
{
db 66h;
movEAX, 3; //may work, likely 1 byte assignment
db 66h;
movEAX, 300; //4 byte assignment from 32bit register
//4 byte padding needed for 64bit.
//Little endian would allow this to work
db 0,0,0,0;
}
But that's mostly informational, refer to the technical manual
from Intel before attempting.
Hmmm I wonder, with the 64 bit systems, do they still use the
segment registers (CS, DS, SS)? I can see it being used for
telling apart virtual memory and code/data, but not for hardly
anything else; Plus it's original use has long since been
unneeded.
Re: Phobos Members-Tuple function?
bearophile wrote: I have not fully understood the problem, but have you tried [__traits(getAttributes, m)] ? yes, that's not really relevant to my problem. 'm' in your example, can't be read at compile time, because __traits(derivedMembers, ..) returns a Tuple of strings, not Symbols. I can get the attributes of a specific member just fine, the problem is iterating over *all* members, then finding the attributes for each member. It's relatively easy to solve with recursion, I'm just trying to cover my tracks here and see if there's a better way I'm unaware of.
Re: Phobos Members-Tuple function?
F i L: I need this for collecting info on all Type Members's User Attributes. Currently, I have written a recursive function which does this, but I'm looking for a more elegant solution. I have not fully understood the problem, but have you tried [__traits(getAttributes, m)] ? Bye, bearophile
BitArray new design - Hashing out general thoughts and ideas (with slices too)
On Saturday, 19 January 2013 at 09:07:03 UTC, Dmitry Olshansky
wrote:
opBinaryAssign --> opOpAssign. opSlice/opSlice assign. In any
case it seems to me that (I think you already did this trick
before) you can reuse a lot of code by making an operator
string a template parameter (for functions that implement =,
|=, &=, ^=, and therefore ^, |, &) and use string mixins.
Yes I did when I could; The slice versions can only forwards
them to the bitarray one.
Other then this - don't forget the '~' _unary_ operator as it
makes a lot of sense for bit-vectors. Now since slices don't
support '~' concatenation it won't look so bad. Worst case:
auto ba = BitArray(...);
auopt slice = ba[...];
ba ~= ~slice;
Only works if you create a new version and append it; And all
opBinary operations make duplicates due to their nature. So the
above couldn't work if slice is a separate type, and instead:
auto slice = ba[...]; //slice type of BitArraySlice
auto bc ~= ~slice; //ba/bc type of BitArray
ba = (ba ~ (~slice))[]; //type of BitArraySlice
And it's not much of problem.
Hmmm.. Well as mentioned I don't think a separate slice/range
type is the best design or as practical; I have it half working
but one problem I'm really having is trying to make sense of the
errors after I converted to use a pointer. It's confusing since
it was compiling before and is an annoyance more-so now; And
suddenly can't deduce the type when it should be able to, and if
I explicitly call it with the type it doesn't help any.
[quote]
Error: template
bitmanip.BitArray!(Fixed!(1024)).BitArray.opEquals(alias
SL)(const SL rhs) if (hasMember!(SL, "isBitArray") ||
hasMember!(SL, "isBitArraySlice")) forward reference to template
opEquals(alias SL)(const SL rhs) if (hasMember!(SL, "isBitArray")
|| hasMember!(SL, "isBitArraySlice"))
Error: template
bitmanip.BitArray!(Fixed!(1024)).BitArray.opEquals cannot deduce
template function from argument types
!()(BitArraySlice!(BitArray!(Fixed!(1024)),
true),const(ulong),const(ulong))
Error: cannot implicitly convert expression
((*this.slice).toString(this.start, this.end)) of type string to
string
[/quote]
[code]
//isBitArray and isBitArraySlice are enums in the structs
//almost all functions templated to handle fixed/dynamic
//types as compatible. Plus constness for range(s).
//auto ref would be nice/preferred in a lot in these functions..
//Otherwise copying is required unless i do more
duplication/code forwarding
//if opSlice is @system, then almost all these are @system, or
@trusted
//slice forwarding
bool opEquals(SL)(const SL rhs) const
if (hasMember!(SL, "isBitArray") || hasMember!(SL,
"isBitArraySlice"))
{
//opSlice always returns BitArraySlice
return opEquals(rhs[], 0, length);
}
bool opEquals(SL)(const SL rhs, ulong sliceStart, ulong
sliceEnd) const
if (hasMember!(SL, "isBitArraySlice"))
{
if ((sliceEnd-sliceStart) != rhs.length)
return false;
return opCmp(rhs, sliceStart, sliceEnd) == 0;
}
//slice forwarding
int opCmp(SL)(const SL rhs) const
if (hasMember!(SL, "isBitArray"))
{
//opSlice always returns BitArraySlice
return opCmp(rhs[], 0, length);
}
int opCmp(SL)(const SL rhs, ulong sliceStart, ulong sliceEnd)
const
if (hasMember!(SL, "isBitArraySlice"));
[/code]
A small consideration was coming to mind in cases where storage
management if you only needed to prepend a few bits or append
just after for a few bits but don't need to do a full
reallocation. In that case perhaps a before/after allocated
memory would serve nice.
size_t beforeArray, afterArray;
int beforeUsed, afterUsed; //course would likely be bitfield or
ubyte
Now if we use that it comes to mind that although it wouldn't be
perfect storage for small compact arrays (as was the original
complaint(s)), you could however rely on them just as much as the
main array and the first size_t bits (*2 if you prepend/append to
the array a lot. It would also be useful to append past the end
of a sliced area without tampering with data outside it's access
area until it's forced to resize.
Fixed BitArraySizes seem far more wanted where you don't want to
do extra memory allocation, so using reference counting wouldn't
work, but with dynamic arrays you could. So if you did all the
slices to a particular bit array could always point to the proper
memory.
If you did do that, prepending to an array would be a nightmare
unless you could offset it with a virtual offset to represent the
actual beginning. So...
//start in the middle
struct STORE {
//virtualOffset instead?
ulong startOffset = ulong.max / 2;
size_t[] store;
}
//in slice/Bitarray, hope that's right
RefCounted!(STORE) store;
ulong start, end;
With these three you can safely do dynamic slices while all
slices point to the same data; in cases where there's only one
reference store, start, en
Phobos Members-Tuple function?
Is there a function in phobos which will return a Tuple of a
Type's members, for use in a foreach statement?
I need this for collecting info on all Type Members's User
Attributes. Currently, I have written a recursive function which
does this, but I'm looking for a more elegant solution.
Let's say I have an Ship Actor class:
class Ship : Actor
{
@Bind("Stage.update") void update()
{
// ...
}
@Bind("Canvas.draw") void draw()
{
// ...
}
}
and I want to iterator over all it's members.. and, in turn,
iterate over all their attributes. If I use
"__traits(derivedMembers, Ship)" it returns a Tuple of strings,
which I can't use with __traits(getAttributes, ..). So what are
my options here? Ideally, I'd like to be able to do this:
auto ship = new Ship;
enum mbrs = membersOf(Ship); // returns Tuple
foreach (m; mbrs)
{
enum atrs = __traits(getAttributes, m);
foreach (a; atrs)
{
if (is(a : Bind))
Engine.bindActors(ship, a.pattern);
}
}
Like I said, I've already accomplished this using recursion. I'm
just wondering if there's an easier way (like above). Also, if
recursive functions are required, I'd love to hear ideas on the
best way to write a general purpose recursive function for this
kind of thing.
Re: Pull 1019
Does anyone else think, that merging this pull: https://github.com/D-Programming-Language/dmd/pull/1428 would be better then waiting for pull 1019? Pull 1428 is ready to merge and use. If someday pull 1019 is ready, it can replace pull 1428. Fact is, that this problem has caused big issues by using structs. That's why a fast solution would be preferable.
Re: Assembly - 64-bit registers supported?
On Saturday, 19 January 2013 at 13:12:47 UTC, deed wrote: Missing -m64 or something? Probably. I am on Windows using dmd 2.061 and optlink 8.00.12 dmd main.d -m64 Con't run 'bin\amd64\link.exe', check PATH Setting LINKCMD64 to the same path as for LINKCMD in sc.ini: dmd main.d -m64 OPTLINK : Warning 9: Unknown Option : MERGE OPTLINK : Error 8: Illegal Filename /NOLOGO prog /MERGE:.minfobg=.minfodt /MERGE:.minfoen=.minfodt /MERGE:._deh_bg=._deh_eh /MERGE:._deh_en=._deh_eh --- errorlevel 1 Do I need another linker? Ach, Windows. Yeah, you need VS Linker when compiling for 64bits on Windows. Can't help you more with this. I think there is somewhere step-by-step guide for 64bits+windows. (wiki.dlang.org maybe? not sure)
Re: Assembly - 64-bit registers supported?
Missing -m64 or something? Probably. I am on Windows using dmd 2.061 and optlink 8.00.12 dmd main.d -m64 Con't run 'bin\amd64\link.exe', check PATH Setting LINKCMD64 to the same path as for LINKCMD in sc.ini: dmd main.d -m64 OPTLINK : Warning 9: Unknown Option : MERGE OPTLINK : Error 8: Illegal Filename /NOLOGO prog /MERGE:.minfobg=.minfodt /MERGE:.minfoen=.minfodt /MERGE:._deh_bg=._deh_eh /MERGE:._deh_en=._deh_eh --- errorlevel 1 Do I need another linker?
Re: Assembly - 64-bit registers supported?
On Saturday, 19 January 2013 at 12:45:06 UTC, deed wrote:
void main()
{
asm
{
movRAX, 3;
}
}
results in:
Error: undefined identifier 'RAX'
AX and EAX work.
Anything missing or isn't it yet implemented?
http://dpaste.dzfl.pl/0f79b5ba
Missing -m64 or something?
Assembly - 64-bit registers supported?
void main()
{
asm
{
movRAX, 3;
}
}
results in:
Error: undefined identifier 'RAX'
AX and EAX work.
Anything missing or isn't it yet implemented?
Re: Pull 1019
On Friday, 18 January 2013 at 20:56:43 UTC, Namespace wrote: Not sure what you mean? Nobody will tell you when your pull fails the unittests. When your pull actually gets merged for real into the "head", you aren't notified either (sadly), but the puller usually leaves a "merged" comment, and you get *that* notification. It isn't my pull but I want to know if this pull is merged in the near future because it fix the "auto ref" problem and that is a very big issue. Also I want to know if someone is working on the pull currently. As they say here: http://forum.dlang.org/thread/pklewzmhquqewkecy...@forum.dlang.org#post-pklewzmhquqewkecyuld:40forum.dlang.org the working on less important things is apparently more important instead to merge something like the "auto ref" pull or the other 116 pulls.
Re: BitArray new design - slice problems
19-Jan-2013 11:14, Era Scarecrow пишет: On Friday, 18 January 2013 at 16:42:04 UTC, Dmitry Olshansky wrote: Slices should have a pointer and length so they can check range (in debug builds), alternatively just a pointer to storage that nows the range. So write an alternate opIndex... I think slice ops could be made @safe if the primitives for bulk transfer and opIndex in the Storage are @trusted. If we just mark all of opSlice on Fixed-sized one as @system then it should be good enough. In other words (I'm lost in terminology): The idea is to make code responsible for the "root" of unsafety to be @system everything else then can be @safe or @trusted(where compiler can't see it). Hmmm okay... Somehow this seemed so much more complex than it's put here. I think that the most of slice ops can be @safe/@trusted. It's the process of taking a slice out of stack-based container that is not @safe. The one taking a slice out of GC-based one is @safe. And depending on if it is fixed or dynamic will determine if the slice is @system or @safe... Makes sense. That sets me straight. So for the slice/range, what all should it support? I've tried to have it support (or foward) opBinary, opBinaryAssign, comparing, slicing, copying, as well as inputRange, bidirectional, opIndex & opIndex assign, opDollar and length. If it should support a much smaller sub-set I'll need to know; Could greatly affect how it is written. opBinaryAssign --> opOpAssign. opSlice/opSlice assign. In any case it seems to me that (I think you already did this trick before) you can reuse a lot of code by making an operator string a template parameter (for functions that implement =, |=, &=, ^=, and therefore ^, |, &) and use string mixins. Other then this - don't forget the '~' _unary_ operator as it makes a lot of sense for bit-vectors. Now since slices don't support '~' concatenation it won't look so bad. Worst case: auto ba = BitArray(...); auopt slice = ba[...]; ba ~= ~slice; And it's not much of problem. -- Dmitry Olshansky
Re: Opening a web
On Saturday, 19 January 2013 at 08:09:01 UTC, Mirko Pilger wrote:
How to open a website in D with your default browser?
import std.process;
int main(string[] args)
{
browse("http://dlang.org";);
return 0;
}
Thank you, man!
Re: Opening a web
How to open a website in D with your default browser?
import std.process;
int main(string[] args)
{
browse("http://dlang.org";);
return 0;
}
