Re: More than one invariant per struct/class
On Sat, 06 Aug 2011 22:53:31 +0200, Jonathan M Davis jmdavisp...@gmx.com wrote: Feel free to create a feature request on it. It may even get the language changed. However, having more than one invariant complicates things a bit, since right now, it's easy for the runtime to just call the one invariant. If you had multiple invariants, they would have to be merged somehow by the compiler. It's completely doable, but it definitely complicates things, which is probably why it doesn't work that way now. unittests are already merged this way, so it should be easy.
Re: Multi-file byte comparison tool. What would you have done differently?
On Fri, 05 Aug 2011 18:43:27 +0200, Kai Meyer k...@unixlords.com wrote: On 08/05/2011 03:02 AM, Pelle wrote: Don't declare variables until you need them, just leave bytes_read and bytes_max here. Is there a performance consideration? Or is it purely a style or D-Factor suggestion? Just style and D-factor :-) Also, resulting code is shorter, and you can replace a lot of type names with auto. I don't understand why you use ByteUnion instead of just a plain array of bytes. I thought that comparing one byte at a time would be slower than comparing 8 bytes at a time (size_t on 64bit) and failing over to the byte-by-byte comparison only when the size_t value was different. Maybe, but that's something that should be benchmarked. If a byte array is just as fast, and the code is simpler, that's a better solution :)
Thread Sleep
I wonder why there isn't any sleep method in std.concurrency. I know there is one in core.thread, but I try to avoid using core modules. Maybe a sleep method is just not needed in std.concurrency? If I were to make a program that would constantly have about 60 working threads. Some kind of sleeping mechanism is a must in my opinion. Someone please answer! ^^ Thanks.
Re: Thread Sleep
On Monday 08 August 2011 07:01:11 BizarreCake wrote: I wonder why there isn't any sleep method in std.concurrency. I know there is one in core.thread, but I try to avoid using core modules. Maybe a sleep method is just not needed in std.concurrency? If I were to make a program that would constantly have about 60 working threads. Some kind of sleeping mechanism is a must in my opinion. Someone please answer! ^^ Thanks. It's not there, because it's in core.thread. We're not going to duplicate code just so that it's in std instead of core. If the functionality that you need is in core, then use core. I don't see any reason to avoid it beyond the fact that a large portion of it is C declarations which Phobos uses to implement nicer, D functions which are then what you'd use. But if it's D code, then there's no reason not to use it. It's there to be used, and it's not going to be duplicated in std. - Jonathan M Davis
Writing .di files duplicate storage
I'm writing here because I haven't been able to create a smaller example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice when writing .di files.
This is my code:
///
static @property isGUIThread() {
return cast(bool)IsGUIThread(false);
}
And this is the generated .di file:
static @property @property isGUIThread()
{
return cast(bool)IsGUIThread(false);
}
I have several other static @property fields too, but this is the only
one affected.
Is this issue already in bugzilla? Or do I have to try to reproduce it
in a smaller testcase?
Re: Writing .di files duplicate storage
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice when writing .di files.
This is my code:
///
static @property isGUIThread() {
return cast(bool)IsGUIThread(false);
}
And this is the generated .di file:
static @property @property isGUIThread()
{
return cast(bool)IsGUIThread(false);
}
I have several other static @property fields too, but this is the only
one affected.
Is this issue already in bugzilla? Or do I have to try to reproduce it
in a smaller testcase?
http://d.puremagic.com/issues/show_bug.cgi?id=6360
Re: Writing .di files duplicate storage
On 08.08.2011 09:47, Jonathan M Davis wrote:
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice when writing .di files.
This is my code:
///
static @property isGUIThread() {
return cast(bool)IsGUIThread(false);
}
And this is the generated .di file:
static @property @property isGUIThread()
{
return cast(bool)IsGUIThread(false);
}
I have several other static @property fields too, but this is the only
one affected.
Is this issue already in bugzilla? Or do I have to try to reproduce it
in a smaller testcase?
http://d.puremagic.com/issues/show_bug.cgi?id=6360
Thanks. The annoying thing is that I have to manually modify the import
library :|
Re: Writing .di files duplicate storage
On Monday, August 08, 2011 12:54:00 AM, simendsjo wrote: On 08.08.2011 09:47, Jonathan M Davis wrote: http://d.puremagic.com/issues/show_bug.cgi?id=6360 Thanks. The annoying thing is that I have to manually modify the import library :| Could spend the time fixing dmd instead of working around the bug. I can't guarantee it'll be actually easier to fix it at the source rather than massaging the output, but I do know that the long term result would be more useful. :)
Re: Writing .di files duplicate storage
On 08.08.2011 09:57, Brad Roberts wrote: On Monday, August 08, 2011 12:54:00 AM, simendsjo wrote: On 08.08.2011 09:47, Jonathan M Davis wrote: http://d.puremagic.com/issues/show_bug.cgi?id=6360 Thanks. The annoying thing is that I have to manually modify the import library :| Could spend the time fixing dmd instead of working around the bug. I can't guarantee it'll be actually easier to fix it at the source rather than massaging the output, but I do know that the long term result would be more useful. :) You really would not like me poking around in the DMD source :) The little C++ I once knew is very rusty, and my compiler theory is eq 0
Re: More than one invariant per struct/class
On 06.08.2011 22:53, Jonathan M Davis wrote:
On Saturday 06 August 2011 22:40:15 simendsjo wrote:
On 04.08.2011 11:32, simendsjo wrote:
I would like to use a template mixin to add some fields to a struct, but
I'd also like the template to add additional invariant checks without
having to remember to add this for all struct/classes that mixes in this
code.
class C {
int a;
}
mixin template EmbedC() {
C _c;
// oops.. more than one invariant
invariant() {
assert(_c);
}
void close() {
_c = null;
}
}
struct S {
int i = 10;
invariant() {
assert(i= 10);
}
mixin EmbedC!();
}
void main() {
S s;
s.close();
s._c.a = 10; // access violation, but I want assertion from invariant
}
Should I create a feature request to support more than one invariant?
It's pretty obvious that it works as designed given the nice error
message though..
Feel free to create a feature request on it. It may even get the language
changed. However, having more than one invariant complicates things a bit,
since right now, it's easy for the runtime to just call the one invariant. If
you had multiple invariants, they would have to be merged somehow by the
compiler. It's completely doable, but it definitely complicates things, which
is probably why it doesn't work that way now.
If you wanted to be able to do it now though, I'd suggest that the mixins not
have invariants but that they have functions which you then have to call in
the invariant of the type that they're being mixed into. It's more error
prone, since you could forget to call one of those functions in the invariant,
but it allows you to have invariants of a sort in the mixed in code and still
only have one invariant for the type.
- Jonathan M Davis
http://d.puremagic.com/issues/show_bug.cgi?id=6453
Re: Writing .di files duplicate storage
On 08.08.2011 10:01, simendsjo wrote:
On 08.08.2011 09:47, Jonathan M Davis wrote:
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice when writing .di files.
This is my code:
///
static @property isGUIThread() {
return cast(bool)IsGUIThread(false);
}
And this is the generated .di file:
static @property @property isGUIThread()
{
return cast(bool)IsGUIThread(false);
}
I have several other static @property fields too, but this is the only
one affected.
Is this issue already in bugzilla? Or do I have to try to reproduce it
in a smaller testcase?
http://d.puremagic.com/issues/show_bug.cgi?id=6360
Wow! That was strange... If you look at my original property, I'm
missing the bool return type. I don't have auto or void as the return
type either. Compiling this gives no warnings!
If I add bool as return type, the duplicate @property is dropped.
Any idea why this even compiles? The documentation doesn't say anything
about @property automatically adding a return type.
http://d.puremagic.com/issues/show_bug.cgi?id=6454
formattedWrite
I cannot find any string format() method in phobos. Having to do: auto a = appender!string(); formattedWrite(a, , ...); a.data seems unnecessary in many cases.
Re: formattedWrite
On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo simend...@gmail.com wrote: I cannot find any string format() method in phobos. What's wrong with format() from std.string? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: formattedWrite
On 08.08.2011 13:37, Vladimir Panteleev wrote: On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo simend...@gmail.com wrote: I cannot find any string format() method in phobos. What's wrong with format() from std.string? Thanks, that was the function I was looking for. I just expected it to be in std.format (and I also looked in std.stdio).
Re: formattedWrite
On 08.08.2011 13:41, simendsjo wrote: On 08.08.2011 13:37, Vladimir Panteleev wrote: On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo simend...@gmail.com wrote: I cannot find any string format() method in phobos. What's wrong with format() from std.string? Thanks, that was the function I was looking for. I just expected it to be in std.format (and I also looked in std.stdio). Seems std.string.format is missing positional arguments..
Unittesting libraries
Is it possible to run unittests in libraries?
The following doesn't work:
l.d
===
module l;
import std.stdio;
int f() { return 1; } // just to make sure it's actually compiled in
unittest {
writeln(Unittest from lib);
assert(false);
}
t.d
===
import l;
import std.stdio;
void main() {
writeln(f());
}
dmd -unittest -lib l
dmd -unittest t l.lib
t.exe
1
Re: formattedWrite
On 08.08.2011 14:07, simendsjo wrote: On 08.08.2011 13:41, simendsjo wrote: On 08.08.2011 13:37, Vladimir Panteleev wrote: On Mon, 08 Aug 2011 14:37:26 +0300, simendsjo simend...@gmail.com wrote: I cannot find any string format() method in phobos. What's wrong with format() from std.string? Thanks, that was the function I was looking for. I just expected it to be in std.format (and I also looked in std.stdio). Seems std.string.format is missing positional arguments.. http://d.puremagic.com/issues/show_bug.cgi?id=6455
Re: Writing .di files duplicate storage
On Mon, 08 Aug 2011 04:01:17 -0400, simendsjo simend...@gmail.com wrote:
On 08.08.2011 09:47, Jonathan M Davis wrote:
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller
example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice when writing .di files.
This is my code:
///
static @property isGUIThread() {
return cast(bool)IsGUIThread(false);
}
And this is the generated .di file:
static @property @property isGUIThread()
{
return cast(bool)IsGUIThread(false);
}
I have several other static @property fields too, but this is the only
one affected.
Is this issue already in bugzilla? Or do I have to try to reproduce it
in a smaller testcase?
http://d.puremagic.com/issues/show_bug.cgi?id=6360
Wow! That was strange... If you look at my original property, I'm
missing the bool return type. I don't have auto or void as the return
type either. Compiling this gives no warnings!
If I add bool as return type, the duplicate @property is dropped.
Any idea why this even compiles? The documentation doesn't say anything
about @property automatically adding a return type.
I don't think it's the @property, I think its the static.
static generally implies auto, for example:
static i = 1;
will compile.
-Steve
DDoc adds filename as given on dmd command line in comment
I use absolute paths in a build script, and Ddoc uses the full path in a comment in the generated files. This makes version control very difficult as all developers has to use the same location (and possibly operating system). Is there a way to avoid this without changing by build script?
Re: Writing .di files duplicate storage
On 08.08.2011 15:33, Steven Schveighoffer wrote:
On Mon, 08 Aug 2011 04:01:17 -0400, simendsjo simend...@gmail.com wrote:
On 08.08.2011 09:47, Jonathan M Davis wrote:
On Monday 08 August 2011 09:42:15 simendsjo wrote:
I'm writing here because I haven't been able to create a smaller
example
and I'm not sure what to search for in bugzilla.
DMD adds a storage identifier twice when writing .di files.
This is my code:
///
static @property isGUIThread() {
return cast(bool)IsGUIThread(false);
}
And this is the generated .di file:
static @property @property isGUIThread()
{
return cast(bool)IsGUIThread(false);
}
I have several other static @property fields too, but this is the only
one affected.
Is this issue already in bugzilla? Or do I have to try to reproduce it
in a smaller testcase?
http://d.puremagic.com/issues/show_bug.cgi?id=6360
Wow! That was strange... If you look at my original property, I'm
missing the bool return type. I don't have auto or void as the return
type either. Compiling this gives no warnings!
If I add bool as return type, the duplicate @property is dropped.
Any idea why this even compiles? The documentation doesn't say
anything about @property automatically adding a return type.
I don't think it's the @property, I think its the static.
static generally implies auto, for example:
static i = 1;
will compile.
-Steve
Seems you are right. Having static on functions also works without
specifying a return type..
Is this by design, or just an implementation oddity?
Re: Writing .di files duplicate storage
simendsjo: Is this by design, or just an implementation oddity? Or a design oddity? Bye, bearophile
IDispatch/activex objects in 2011
I need to interface with an application that has an IDispatch (activex/ole/automation) interface. I can find some threads from 2006 about how painful that was. I'm suspecting that in the intervening 5 years progress has been made, but I'm having trouble finding it. The manual says D interfaces are descended from IUnknown, which would help me to CREATE an IDispatch object, but how do I use one that already exists?
Re: IDispatch/activex objects in 2011
On 08.08.2011 15:46, Jason King wrote: I need to interface with an application that has an IDispatch (activex/ole/automation) interface. I can find some threads from 2006 about how painful that was. I'm suspecting that in the intervening 5 years progress has been made, but I'm having trouble finding it. The manual says D interfaces are descended from IUnknown, which would help me to CREATE an IDispatch object, but how do I use one that already exists? I've used Juno[1] in the past for COM programming. The project seems dead, and probably don't compile with newer DMD versions, but you might be able to figure out what it does. [1] http://dsource.org/projects/juno
Re: Multi-file byte comparison tool. What would you have done differently?
On 08/08/2011 12:33 AM, Pelle wrote: On Fri, 05 Aug 2011 18:43:27 +0200, Kai Meyer k...@unixlords.com wrote: On 08/05/2011 03:02 AM, Pelle wrote: Don't declare variables until you need them, just leave bytes_read and bytes_max here. Is there a performance consideration? Or is it purely a style or D-Factor suggestion? Just style and D-factor :-) Also, resulting code is shorter, and you can replace a lot of type names with auto. I don't understand why you use ByteUnion instead of just a plain array of bytes. I thought that comparing one byte at a time would be slower than comparing 8 bytes at a time (size_t on 64bit) and failing over to the byte-by-byte comparison only when the size_t value was different. Maybe, but that's something that should be benchmarked. If a byte array is just as fast, and the code is simpler, that's a better solution :) I simply can't imagine how 8,000 byte comparisons would be even close to comparable to 1,000 size_t comparisons done one at a time, with the way I'm doing the comparison. I'm certain there are much better ways of comparing bits, but I'm not ready to make this program that complex :)
We have slices, do we have Strides?
I have a problem I'd really like to use Strides for to simplify my code. Currently, I do this: foreach(n; 0..chunks) comp_arr[n] = values[(n * step_size) + n] if(!all_same(comp_arr, comp_arr[0])) It would eliminate an entire 2 lines of code for each time I want strides, to be able to do this: if(!all_same(bytes[i..$..step_size]) Meaning, start with i, grab all elements at i + block_size * n until block_size * n bytes.length. Right? -Kai Meyer
Re: We have slices, do we have Strides?
I have a problem I'd really like to use Strides for to simplify my code. Currently, I do this: foreach(n; 0..chunks) comp_arr[n] = values[(n * step_size) + n] if(!all_same(comp_arr, comp_arr[0])) It would eliminate an entire 2 lines of code for each time I want strides, to be able to do this: if(!all_same(bytes[i..$..step_size]) Meaning, start with i, grab all elements at i + block_size * n until block_size * n bytes.length. Right? -Kai Meyer Would std.range.stride work for you? - Jonathan M Davis
Re: Foreach over tuple of arrays?
Hi Sean,
This doesn't work when passing a delegate as func, however. Is there a way to
circumvent this?
I tried this with a delegate and a function template, it seems to work:
import std.typecons;
void bar(T)(ref T elem)
{
elem = elem+1;
}
void main()
{
auto data = tuple([0,1,2,3], [3,2,1], [0,1]);
auto foo = (ref int i){ i = i * i;};
writeln(data);
foreach(index, range; data.expand)
foreach(ref element; range)
foo(element);
writeln(data);
foreach(index, range; data.expand)
foreach(ref element; range)
bar(element);
writeln(data);
}
data.expand is only needed to get access to the underlying expression
template in the 'data' tuple.
Your own ArrayTuple!(T) may have other way to do that.
Tuple [] operator
Hi,
I'm receiving this error with dmd 2.054:
tmp.d(7): Error: no [] operator overload for type Tuple!(int,short) for
the following test case
import std.typecons;
void main() {
auto x = 1;
Tuple!(int,short) a;
a[0] = 1;
a[x] = 2;
}
If I use a value instead of a variable ie. a[1] = 2; it compiles fine.
A search turned up http://d.puremagic.com/issues/show_bug.cgi?id=6273 and
http://d.puremagic.com/issues/show_bug.cgi?id=6342 though they specifically
mention the use of pure functions which I'm not using. Is this the same
problem anyway?
Chris
Re: Foreach over tuple of arrays?
Hmm, I just saw your question on SO. Is that nearer to what you ask?
It uses a anonymous template function:
import std.typecons;
void act(alias fun, T...)(ref Tuple!T data)
{
foreach(index, range; data.expand)
foreach(ref element; range)
fun(element);
}
void main()
{
auto data = tuple([0,1,2,3], [3,2,1], [0,1]);
writeln(data);
act!( (i) { return i+1; })(data);
writeln(data);
}
Philippe
Re: Tuple [] operator
Hi Chris,
import std.typecons;
void main() {
auto x = 1;
Tuple!(int,short) a;
a[0] = 1;
a[x] = 2;
}
If I use a value instead of a variable ie. a[1] = 2; it compiles fine.
The index need to be a compile-time constant, you cannot index a tuple
with a runtime value.
Try using
enum x = 1;
Philippe
Re: Modify thread-local storage from parent thread
On Mon, 08 Aug 2011 14:17:28 -0400, Kai Meyer k...@unixlords.com wrote: I am playing with threading, and I am doing something like this: file.rawRead(bytes); auto tmpTask = task!do_something(bytes.idup); task_pool.put(tmpTask); Is there a way to avoid the idup (or can somebody explain why idup here is not expensive?) I'd have to see where bytes is created, if it's created in the same context, just casting to immutable is allowed, as long as you never use the mutable reference again. If the logic above is expressed as: Read bytes into an array Create a thread (task) to execute a function that takes a copy of 'bytes' Execute the thread I wonder if I could: Create a thread (task) Read bytes directly into the tasks' thread local storage Execute the thread This *might* be possible. However, in many cases, the OS is responsible for creating the TLS when the thread starts, so you have to wait until the thread is actually running to access it (not an expert on this, but I think this is the case for everything but OSX?) So you would have to create the thread, have it pause while you fill it's TLS, then resume it. But I think this is clearly a weird approach to this problem. Finding a way to reliably pass the data to the sub-thread seems more appropriate. BTW, I've dealt with having to access other threads' TLS. It's not pretty, and I don't recommend using it except in specialized situations (mine was adding a GC hook). -Steve
Re: Tuple [] operator
On 08.08.2011 23:27, Christian Manning wrote:
Hi,
I'm receiving this error with dmd 2.054:
tmp.d(7): Error: no [] operator overload for type Tuple!(int,short) for
the following test case
import std.typecons;
void main() {
auto x = 1;
Tuple!(int,short) a;
a[0] = 1;
a[x] = 2;
}
If I use a value instead of a variable ie. a[1] = 2; it compiles fine.
A search turned up http://d.puremagic.com/issues/show_bug.cgi?id=6273 and
http://d.puremagic.com/issues/show_bug.cgi?id=6342 though they specifically
mention the use of pure functions which I'm not using. Is this the same
problem anyway?
Your case seems simple, it means you can't index tuple with variable as
index, only with something known at compile time.
Replace auto with enum and you are fine, you can even call a function
using CTFE to get an index.
--
Dmitry Olshansky
Re: Tuple [] operator
Philippe Sigaud wrote:
Hi Chris,
import std.typecons;
void main() {
auto x = 1;
Tuple!(int,short) a;
a[0] = 1;
a[x] = 2;
}
If I use a value instead of a variable ie. a[1] = 2; it compiles fine.
The index need to be a compile-time constant, you cannot index a tuple
with a runtime value.
Try using
enum x = 1;
Philippe
Ah I didn't know this, thanks. That makes a tuple pretty useless for what I
was doing now as I was reading the index in from a file. Guess I'll find
another way round it.
Thanks
Chris
Re: Tuple [] operator
On Mon, 08 Aug 2011 15:47:36 -0400, Christian Manning
cmanning...@gmail.com wrote:
Philippe Sigaud wrote:
Hi Chris,
import std.typecons;
void main() {
auto x = 1;
Tuple!(int,short) a;
a[0] = 1;
a[x] = 2;
}
If I use a value instead of a variable ie. a[1] = 2; it compiles fine.
The index need to be a compile-time constant, you cannot index a tuple
with a runtime value.
Try using
enum x = 1;
Philippe
Ah I didn't know this, thanks. That makes a tuple pretty useless for
what I
was doing now as I was reading the index in from a file. Guess I'll
find
another way round it.
You still can do it, but you have to do it by still using compile-time
constants as indexes:
auto x = 1;
Tuple!(int, short) a;
a[0] = 1;
switch(x)
{
case 0:
a[0] = 2;
break;
case 1:
a[1] = 2;
break;
default:
assert(0, does not compute!);
}
the point is, the compiler has no idea what the lvalue expression's type
should be when you do:
a[x] = 1;
is it short or int?
so the compiler must *know* what type x is at compile time in order for
this to be valid.
-Steve
Re: Tuple [] operator
On Mon, 08 Aug 2011 15:55:38 -0400, Steven Schveighoffer wrote:
On Mon, 08 Aug 2011 15:47:36 -0400, Christian Manning
cmanning...@gmail.com wrote:
[...]
auto x = 1;
Tuple!(int, short) a;
a[0] = 1;
switch(x)
{
case 0:
a[0] = 2;
break;
case 1:
a[1] = 2;
Those assignments are now bound at compile time.
break;
default:
assert(0, does not compute!);
}
the point is, the compiler has no idea what the lvalue expression's type
should be when you do:
a[x] = 1;
is it short or int?
so the compiler must *know* what type x is at compile time in order for
this to be valid.
I think it's more import for the compiler to know what type a[x] is. The
assignment operators of different types are different. On the other hand,
I don't think a short vs int would make a difference when it comes to
indexing (it shouldn't anyway).
-Steve
Ali
Re: Tuple [] operator
On Mon, 08 Aug 2011 20:32:03 +, Ali Çehreli wrote: the point is, the compiler has no idea what the lvalue expression's type should be when you do: a[x] = 1; is it short or int? so the compiler must *know* what type x is at compile time in order for this to be valid. I think it's more import for the compiler to know what type a[x] is. The assignment operators of different types are different. On the other hand, I don't think a short vs int would make a difference when it comes to indexing (it shouldn't anyway). -Steve Ali I correct myself before Steve does: I missed the lvalue above. Steve meant a[x] anyway. Ali
Re: Tuple [] operator
On Mon, Aug 8, 2011 at 21:55, Steven Schveighoffer schvei...@yahoo.com wrote:
You still can do it, but you have to do it by still using compile-time
constants as indexes:
auto x = 1;
Tuple!(int, short) a;
a[0] = 1;
switch(x)
{
case 0:
a[0] = 2;
break;
case 1:
a[1] = 2;
break;
default:
assert(0, does not compute!);
}
Christian, I think Steven even suggested in an article some months ago
that this big switch could be generated at compile time.
Steven, do you have a link somewhere?
I mean, the tuple length is known as C-T. It's easy to loop on it and
build a string of cases. If you wrap it in a function, it becomes a
runtime switcher.
Proof of concept:
import std.typecons;
string generateSwitches(T...)()
{
string result = switch(x) {\n;
foreach(i,Type; T)
{
result ~= case ~ to!string(i) ~ :\n
~ fun(tup[ ~ to!string(i) ~ ]);\n
~ break;\n;
}
return result ~ default:\n
~ assert(0, q{Bad index: } ~ to!string(x));\n};
}
void actOnTuple(alias fun, T...)(int x, ref Tuple!T tup)
{
mixin(generateSwitches!(T));
}
void foo(T)(ref T t) { writeln(t); t = T.init;}
void main()
{
auto tup = tuple(1, 3.14, abc);
auto x = 1;
actOnTuple!foo(x, tup);
writeln(tup);
}
Philippe
Re: Tuple [] operator
Philippe Sigaud wrote:
On Mon, Aug 8, 2011 at 21:55, Steven Schveighoffer schvei...@yahoo.com
wrote:
You still can do it, but you have to do it by still using compile-time
constants as indexes:
auto x = 1;
Tuple!(int, short) a;
a[0] = 1;
switch(x)
{
case 0:
a[0] = 2;
break;
case 1:
a[1] = 2;
break;
default:
assert(0, does not compute!);
}
Christian, I think Steven even suggested in an article some months ago
that this big switch could be generated at compile time.
Steven, do you have a link somewhere?
I mean, the tuple length is known as C-T. It's easy to loop on it and
build a string of cases. If you wrap it in a function, it becomes a
runtime switcher.
Proof of concept:
import std.typecons;
string generateSwitches(T...)()
{
string result = switch(x) {\n;
foreach(i,Type; T)
{
result ~= case ~ to!string(i) ~ :\n
~ fun(tup[ ~ to!string(i) ~ ]);\n
~ break;\n;
}
return result ~ default:\n
~ assert(0, q{Bad index: } ~ to!string(x));\n};
}
void actOnTuple(alias fun, T...)(int x, ref Tuple!T tup)
{
mixin(generateSwitches!(T));
}
void foo(T)(ref T t) { writeln(t); t = T.init;}
void main()
{
auto tup = tuple(1, 3.14, abc);
auto x = 1;
actOnTuple!foo(x, tup);
writeln(tup);
}
Philippe
I haven't used string mixins before so I suppose this is a good time to
learn!
Thanks for the help, Steven and Philippe.
Chris
Re: We have slices, do we have Strides?
On 08/08/2011 12:55 PM, Jonathan M Davis wrote: I have a problem I'd really like to use Strides for to simplify my code. Currently, I do this: foreach(n; 0..chunks) comp_arr[n] = values[(n * step_size) + n] if(!all_same(comp_arr, comp_arr[0])) It would eliminate an entire 2 lines of code for each time I want strides, to be able to do this: if(!all_same(bytes[i..$..step_size]) Meaning, start with i, grab all elements at i + block_size * n until block_size * n bytes.length. Right? -Kai Meyer Would std.range.stride work for you? - Jonathan M Davis It would, if there was a way to give it an offset: int[] a = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 ]; assert(equal(stride(a, 3), [ 1, 4, 7, 10 ][])); assert(equal(stride(a, 3, 1), [ 2, 5, 8, 11 ][])); assert(equal(stride(a, 3, 2), [ 3, 6, 9 ][])); assert(equal(stride(a, 3, 3), [ 4, 7, 10 ][])); Is that possible?
Re: We have slices, do we have Strides?
On 08/08/2011 12:55 PM, Jonathan M Davis wrote: I have a problem I'd really like to use Strides for to simplify my code. Currently, I do this: foreach(n; 0..chunks) comp_arr[n] = values[(n * step_size) + n] if(!all_same(comp_arr, comp_arr[0])) It would eliminate an entire 2 lines of code for each time I want strides, to be able to do this: if(!all_same(bytes[i..$..step_size]) Meaning, start with i, grab all elements at i + block_size * n until block_size * n bytes.length. Right? -Kai Meyer Would std.range.stride work for you? - Jonathan M Davis It would, if there was a way to give it an offset: int[] a = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 ]; assert(equal(stride(a, 3), [ 1, 4, 7, 10 ][])); assert(equal(stride(a, 3, 1), [ 2, 5, 8, 11 ][])); assert(equal(stride(a, 3, 2), [ 3, 6, 9 ][])); assert(equal(stride(a, 3, 3), [ 4, 7, 10 ][])); Is that possible? The simplest way is to just pop off the appropriate number of elements from the front. Now, maybe stride should be enhanced to take an offset, but you can do it by just popping off the appropriate number of elements first. Another option would be drop, if it ends up in the next release: https://github.com/D-Programming-Language/phobos/pull/147 It would allow you to drop pop the elements from a slice of a which would then be passed to stride instead of having to create a slice and pop off the elements before calling stride. If it gets into Phobos though, that probably makes it so that there's no real need to make stride take an offset. Regardless, for the moment, it looks like you need to pop off the appropriate number of elements from a (or a slice of a) before passing it to stride if you want an offset. - Jonathan M Davis
Re: We have slices, do we have Strides?
On Mon, 08 Aug 2011 18:33:55 -0400, Kai Meyer k...@unixlords.com wrote: On 08/08/2011 12:55 PM, Jonathan M Davis wrote: I have a problem I'd really like to use Strides for to simplify my code. Currently, I do this: foreach(n; 0..chunks) comp_arr[n] = values[(n * step_size) + n] if(!all_same(comp_arr, comp_arr[0])) It would eliminate an entire 2 lines of code for each time I want strides, to be able to do this: if(!all_same(bytes[i..$..step_size]) Meaning, start with i, grab all elements at i + block_size * n until block_size * n bytes.length. Right? -Kai Meyer Would std.range.stride work for you? - Jonathan M Davis It would, if there was a way to give it an offset: int[] a = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 ]; fixed: assert(equal(stride(a, 3), [ 1, 4, 7, 10 ][])); assert(equal(stride(a[1..$], 3), [ 2, 5, 8, 11 ][])); assert(equal(stride(a[2..$], 3), [ 3, 6, 9 ][])); assert(equal(stride(a[3..$], 3), [ 4, 7, 10 ][])); -Steve
Permission denied under Ubuntu.
Hi, all. I installed dmd_2.054-0_amd64.deb on Ubuntu 11.04, and the compiler seems to work fine, but I can't execute its output. Here's what I'm doing: (ls to show directory contents) $ dmd testFile.d $ ./testFile bash: ./testFile: Permission denied testFile.d is the Hello world program exactly as it appears on page 1 of TDPL. Has anyone else had this issue? If it helps, I let the software center thing do the installing, so if I need to manually change the permission of something, I probably haven't done that.
Re: We have slices, do we have Strides?
On Mon, 08 Aug 2011 18:33:55 -0400, Kai Meyer k...@unixlords.com wrote: On 08/08/2011 12:55 PM, Jonathan M Davis wrote: I have a problem I'd really like to use Strides for to simplify my code. Currently, I do this: foreach(n; 0..chunks) comp_arr[n] = values[(n * step_size) + n] if(!all_same(comp_arr, comp_arr[0])) It would eliminate an entire 2 lines of code for each time I want strides, to be able to do this: if(!all_same(bytes[i..$..step_size]) Meaning, start with i, grab all elements at i + block_size * n until block_size * n bytes.length. Right? -Kai Meyer Would std.range.stride work for you? - Jonathan M Davis It would, if there was a way to give it an offset: int[] a = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 ]; fixed: assert(equal(stride(a, 3), [ 1, 4, 7, 10 ][])); assert(equal(stride(a[1..$], 3), [ 2, 5, 8, 11 ][])); assert(equal(stride(a[2..$], 3), [ 3, 6, 9 ][])); assert(equal(stride(a[3..$], 3), [ 4, 7, 10 ][])); LOL. Yes. Since he's dealing with arrays rather than a generic input range, that works great. - Jonathan M Davis
Re: Tuple [] operator
On 8/8/11, Steven Schveighoffer schvei...@yahoo.com wrote: I like this idea. I think it belongs in phobos somewhere, if not already. -Steve Allow me to +1 on that, I've had a need for this (but now I can't remember why, hah!).
Tuple vs struct performance?
Do you know the cause of the large (something like 3 times, latest dmd, -O -release -inline) difference in performance in this program from using a tuple or a struct with the same fields (the two alternative lines near the top)? http://codepad.org/dLLdgrq8 I have tried in various ways to understand the cause, but I have not found it yet. Bye and thank you, bearophile
Re: Permission denied under Ubuntu.
On Mon, Aug 8, 2011 at 4:30 PM, Charles McAnany mcana...@rose-hulman.eduwrote: Hi, all. I installed dmd_2.054-0_amd64.deb on Ubuntu 11.04, and the compiler seems to work fine, but I can't execute its output. Here's what I'm doing: (ls to show directory contents) $ dmd testFile.d $ ./testFile bash: ./testFile: Permission denied testFile.d is the Hello world program exactly as it appears on page 1 of TDPL. Has anyone else had this issue? If it helps, I let the software center thing do the installing, so if I need to manually change the permission of something, I probably haven't done that. Try `chmod +x dmd` (when in the same directory as the dmd executable). That should get fixed in the package though.
Re: Tuple [] operator
Sorry, wasn't me... Oops, sorry. I like this idea. I think it belongs in phobos somewhere, if not already. I remember getting the idea in one of the articles written to win an iPad2 a few months ago. Philippe
Subclass template arguments from a non-templated interface
I have the following (sort of) situation:
interface Handle
{ }
class A(T...) : Handle
{
T[0] m_one;
T[1] m_two;
etc..
T[0] getOne() { return m_one; }
}
class B
{
Handle[] m_array;
}
The reason I want to inherit A from Handle is so I don't have to keep using the
variadic template arguments on any class which wants to have a member of type A
(T...). In my case there are many possible combinations for the template
arguments (T...). The problem is that Handle doesn't know anything about the
types of the members of A, so it can't (I think) provide an interface to any
functions in A like 'getOne()'. So it can't give me the accessor functions I
need to get at A's data (or maybe i'm wrong?).
Is there a neat way for a class like A(T...) to enable Handle to cast to its (A!
T's) type? Like some way of having Handle call a function in A which returns or
somehow gives Handle a typetuple of the template arguments to A? Since Handle
can only call functions in A which it defines itself, I don't think this is
possible?
Or am I just going about this all wrong? I just need some kind of generic
handle to objects of type A(T...) which can cast itself to its specific A!T
when needed. I know the A(T...)'s are all different types to the compiler, but
D seems to have lots of tricks up its sleeve.
Many thanks!
