Re: Using traits how do i get a function's parameters as a string?
On 2013-09-03 23:32, Adam D. Ruppe wrote: How do I keep missing these new std.traits things? Very nice. Because they just magically shows up :) -- /Jacob Carlborg
Re: Little demo of allowing basic types to implement interfaces. Was in D.annouce
Just wondering if this exists in the standard library.
I made a function Implements!(T,I) that returns true is a given
type T implements the interface I.
http://dpaste.dzfl.pl/d7a727fd
I've found it really helps with keeping some code clean such as
the below:
void main() {
int i = 0x34342343;
writebytes(i);
}
//enum Order { Big };
//interface IRawBytes { ubyte[] bytes(Order); }
interface IRawBytes { ubyte[] bytes(); }
void writebytes(T)(T item) if (Implements!(T, IRawBytes)) {
import std.stdio : writeln;
writeln(item.bytes);
}
ubyte[] bytes(ref int i) {
ubyte* ptr;
ptr = cast(ubyte*)i;
return ptr[0..i.sizeof];
}
If you decide that IRawBytes.bytes should start taking an Order
parameter you get the same benefits you would have got if you had
used classes with an interface.
Re: Little demo of allowing basic types to implement interfaces. Was in D.annouce
It does not exist and often (re)implemented by different people here and there. There still few issues that do not make it vastly more superior than existing `isInputRange!T` and friends - I guess this is why no one bothered submitting pull requests to the Phobos in the end. 1) You have already stumbled upon this. The fact that templates are evaluated at declaration scope + UFCS makes it almost useless as generic template. `std.range` imports `std.array` workaround this for most common case but this remain unsolved problem in general. 2) You can't check for behavior with it, only for signatures (and may be subject to any type comparison quirks) 3) It still does not give you the power of Go interfaces / Rust traits - one can't use interface parameter type to pass in a struct that matches it (via automatically generated fat pointer)
Re: Pitfalls of delegates inside ranges
On 09/03/13 12:00, Sönke Ludwig wrote:
Am 02.09.2013 15:39, schrieb Artur Skawina:
this(this) { jump.ptr = this; }
Just a warning: This can still easily crash due to D's struct move semantics.
Structs are moved around sometimes without any postblit constructor or
destructor being called, so fixing self-references like this won't work in
general.
Yes. Thanks for catching this.
I tend to ignore the broken/hacky/incomplete parts of the language,
and forgot about it.
artur
Re: Pitfalls of delegates inside ranges
On 03/09/13 12:00, Sönke Ludwig wrote: Just a warning: This can still easily crash due to D's struct move semantics. Structs are moved around sometimes without any postblit constructor or destructor being called, so fixing self-references like this won't work in general. Is the patch to Phobos risky, then? I'll switch to an alternative design if so.
Re: Using traits how do i get a function's parameters as a string?
On 9/3/13, Adam D. Ruppe destructiona...@gmail.com wrote:
On Tuesday, 3 September 2013 at 21:20:04 UTC, Andrej Mitrovic
wrote:
foreach (id; ParameterIdentifierTuple!func)
How do I keep missing these new std.traits things? Very nice.
It's really funky that an is() expression is used to extract this:
static if (is(FunctionTypeOf!func PT == __parameters)) { }
I'd assume it would be __traits(getParams, ...).
Re: Pitfalls of delegates inside ranges
On 09/04/13 13:42, Joseph Rushton Wakeling wrote: On 03/09/13 12:00, Sönke Ludwig wrote: Just a warning: This can still easily crash due to D's struct move semantics. Structs are moved around sometimes without any postblit constructor or destructor being called, so fixing self-references like this won't work in general. Is the patch to Phobos risky, then? I'll switch to an alternative design if so. No, like i said, that's not how I'd do it (I would make `this` explicit and avoid all those issues), but that last patch /will/ work. The problem is with *pointers* inside an object that point to that same object. 'Pointers' includes delegates (those contain a context pointer). You're not storing any pointers, so it's ok. It was my first quick fix, which attempted to update the context pointer in the postblit, that was wrong. artur
Re: Using traits how do i get a function's parameters as a string?
On 2013-09-04 13:54, Andrej Mitrovic wrote:
It's really funky that an is() expression is used to extract this:
static if (is(FunctionTypeOf!func PT == __parameters)) { }
I'd assume it would be __traits(getParams, ...).
I agree. Wonder why this approach was chosen.
--
/Jacob Carlborg
Re: Newbie questions. Which Compiler to start with? Real Time behaviour? Has anyone converted CImg yet?
On Monday, 2 September 2013 at 02:38:35 UTC, bearophile wrote: John Carter: How easy is it to convert both C++ programs and C++ programmers to D? Porting C code to D is not hard, it's mostly mechanical work, you just have to keep an eye on few things (like passing fixed-sized arrays to functions by reference, global floating point data not initialized to zero, etc). I think that for a C++ programmer it's not too much hard to learn D. But converting C++ code to D could be very hard (and a slow work) if the code uses lot of small things that are specific of C++ and missing or different in D. If the C++ code is more plain, then it's probably not hard, despite the missing multiple inheritance and struct inheritance. Converting CImg to D seems a multi-years work. Bye, bearophile While I just had a brief look at CImg and am thus far from an expert I wonder if developing a similar project in D would be quite that bad. There seems like a lot of the code isn't core functionality for an image processing library. The whole header file is 40+K lines of code. The system seems to include its own cross-platform image/graphics rendering system. There are 1100+ loc are just static arrays storing fonts. Furthermore, while it does seem to include a tonne of image processing functions, I am sure a basic library could initially omit many of these. For example there is a math formula parser that accounts for a huge chunk of the library. Certainly something you would want to have in the long run, but might be omitted initially. Finally, the use of templates seems fairly straightforward - at least by my brief perusal, and the code is more C like that C++ like. It doesn't appear to have a complex object hierarchy at all. So, I think this might be doable if: 1. You skipped the image display system (that shouldn't be part of a library in my opinion anyway). 2. You identified what your priority functionality would be and (initially at least) dropped the others [eg. the math formula parser]. Craig
Support implicit conversion between types
I have some code like this:
struct Foo
{
this(int i)
{
//do something useful
}
}
void bar(Foo f)
{
//do something else
}
void main()
{
Foo f = 5;//works
bar(f);//works
bar(Foo(5));//works
bar(5);//Error: function app.bar (Foo f) is not callable using
argument types (int)
}
D can't implicitly convert type int to type Foo, but
constructor Foo(int) exists. Explicit conversion works fine.
What should I do to support this convertion implicitly?
Re: Support implicit conversion between types
On Wednesday, 4 September 2013 at 19:44:17 UTC, Namespace wrote:
What's about:
void bar(int i) {
bar(Foo(i));
}
?
No, I wrote very simple example. I have 10 from types and a lot
of different bar functions. Your way will be more painful then
explicit conversion.
Re: Support implicit conversion between types
So you can use templates, something like this:
bool isConvertableToFoo(T)
{
T i = void;
return is(typeof(Foo(i)) == Foo);
}
void bar(T)(T i) if (is(T : Foo))
{
//some code
}
void bar(T)(T i) if (!is(T : Foo) isConvertableToFoo!T)
{
bar(Foo(i));
}
I do not test it so it is maybe not completly correct :).
On Wednesday, 4 September 2013 at 19:54:44 UTC, ilya-stromberg
wrote:
On Wednesday, 4 September 2013 at 19:44:17 UTC, Namespace wrote:
What's about:
void bar(int i) {
bar(Foo(i));
}
?
No, I wrote very simple example. I have 10 from types and a
lot of different bar functions. Your way will be more painful
then explicit conversion.
Re: Support implicit conversion between types
On Wednesday, 4 September 2013 at 20:14:06 UTC, Kozzi wrote: So you can use templates, something like this: I know, it will work. But I really have **a lot of** different bar functions, so that way will be painful. So, the question is: what should I add to Foo struct to allow implicit conversions from int to Foo?
Re: Support implicit conversion between types
On Wednesday, 4 September 2013 at 20:25:28 UTC, ilya-stromberg
wrote:
So, the question is: what should I add to Foo struct to allow
implicit conversions from int to Foo?
D does not support implicit struct construction.
Interestingly though, it *does* support it for functions taking
classes:
class Foo {
this(int i) {}
}
void foo(Foo f...) {}
void main() {
foo(10);
}
But there's nothing like it for structs.
Re: Support implicit conversion between types
On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:
D does not support implicit struct construction.
That's what I knew.
Interestingly though, it *does* support it for functions taking classes:
class Foo {
this(int i) {}
}
void foo(Foo f...) {}
void main() {
foo(10);
}
WHAT? :) It even new's one?
But it works only for the ellipsis.
I wonder why the discrepancy...
Ali
Re: Support implicit conversion between types
On Wednesday, 4 September 2013 at 21:14:26 UTC, Ali Çehreli wrote:
On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:
D does not support implicit struct construction.
That's what I knew.
Interestingly though, it *does* support it for functions
taking classes:
class Foo {
this(int i) {}
}
void foo(Foo f...) {}
void main() {
foo(10);
}
WHAT? :) It even new's one?
But it works only for the ellipsis.
I wonder why the discrepancy...
Ali
http://dlang.org/function.html Under Typesafe Variadic Functions
- For class objects.
Re: Support implicit conversion between types
On Wed, Sep 04, 2013 at 02:14:26PM -0700, Ali Çehreli wrote:
On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:
D does not support implicit struct construction.
That's what I knew.
Interestingly though, it *does* support it for functions taking
classes:
class Foo {
this(int i) {}
}
void foo(Foo f...) {}
void main() {
foo(10);
}
WHAT? :) It even new's one?
But it works only for the ellipsis.
I wonder why the discrepancy...
[...]
Whoa. I never knew about this! It's ... I don't know what to say. It
seems to be a cool feature, but it's also ... so scary. Implicit new's
just leaves a lump in my throat. Is this an actual, intentional
feature??!
T
--
If you want to solve a problem, you need to address its root cause, not just
its symptoms. Otherwise it's like treating cancer with Tylenol...
Multidimensional dynamic array of strings initialized with split()
Hello friends,
with the following code
import std.stdio;
import std.array;
auto file71 = File(argv[2], r);
string[][] buffer;
foreach (line; file71.byLines) {
buffer ~= split(line, \t);
}
I am trying to cut the lines from the file with tab as delimiter
to pre-fetch the content of a file before further processing.
Each split() call gives correct string[] values in and of itself.
But when I try to read buffer, after the loop, I got corrupted
data, like this:
[ [-, _Unit226, constructor,
sub_00BE896C\t1\t?:?\t\t//con, t, uc...
Obviously the concatenation is doing no good, since there are
tabs in the values...
What am I missing here ? Is it that split() allocated memory that
gets overwritten in the loop and the ~= just copies the subarrays
not copying the subsubarrays ? How to overcome this ?
Thank you very much,
Ludovit
Re: Multidimensional dynamic array of strings initialized with split()
On Thu, Sep 05, 2013 at 12:57:34AM +0200, Ludovit Lucenic wrote:
Hello friends,
with the following code
import std.stdio;
import std.array;
auto file71 = File(argv[2], r);
string[][] buffer;
foreach (line; file71.byLines) {
buffer ~= split(line, \t);
}
I am trying to cut the lines from the file with tab as delimiter to
pre-fetch the content of a file before further processing.
Each split() call gives correct string[] values in and of itself.
But when I try to read buffer, after the loop, I got corrupted data,
like this:
[ [-, _Unit226, constructor, sub_00BE896C\t1\t?:?\t\t//con,
t, uc...
Obviously the concatenation is doing no good, since there are tabs
in the values...
What am I missing here ? Is it that split() allocated memory that
gets overwritten in the loop and the ~= just copies the subarrays
not copying the subsubarrays ? How to overcome this ?
[...]
The problem is that File.byLine() reuses its buffer for efficiency, and
split is optimized to return slices into that buffer instead of copying
each substring. So after every iteration the buffer (and therefore the
slices into it) gets overwritten.
Replace the loop body with the following and it should work:
buffer ~= split(line.dup, \t);
T
--
Dogs have owners ... cats have staff. -- Krista Casada
Re: Support implicit conversion between types
On Thu, Sep 05, 2013 at 01:04:30AM +0200, Kapps wrote:
On Wednesday, 4 September 2013 at 23:00:07 UTC, H. S. Teoh wrote:
On Wed, Sep 04, 2013 at 02:14:26PM -0700, Ali Çehreli wrote:
On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:
D does not support implicit struct construction.
That's what I knew.
Interestingly though, it *does* support it for functions taking
classes:
class Foo {
this(int i) {}
}
void foo(Foo f...) {}
void main() {
foo(10);
}
WHAT? :) It even new's one?
But it works only for the ellipsis.
I wonder why the discrepancy...
[...]
Whoa. I never knew about this! It's ... I don't know what to say. It
seems to be a cool feature, but it's also ... so scary. Implicit
new's just leaves a lump in my throat. Is this an actual, intentional
feature??!
T
It, in theory, doesn't allocate memory:
An implementation may construct the object or array instance on the
stack. Therefore, it is an error to refer to that instance after the
variadic function has returned
That's even more scary. So the object implicitly constructed in this way
is put on the *stack* instead of the heap, and becomes invalid after the
function returns? That's just a minefield of pitfalls waiting to
happen...
T
--
Curiosity kills the cat. Moral: don't be the cat.
Re: Multidimensional dynamic array of strings initialized with split()
On Wednesday, 4 September 2013 at 23:06:10 UTC, H. S. Teoh wrote: The problem is that File.byLine() reuses its buffer for efficiency, and split is optimized to return slices into that buffer instead of copying each substring. So after every iteration the buffer (and therefore the slices into it) gets overwritten. Replace the loop body with the following and it should work: buffer ~= split(line.dup, \t); T Thank you so much for your explanation. Helped me a lot to understand things and works actually :-) LL
Re: Support implicit conversion between types
On Wed, Sep 04, 2013 at 04:07:28PM -0700, H. S. Teoh wrote:
On Thu, Sep 05, 2013 at 01:04:30AM +0200, Kapps wrote:
On Wednesday, 4 September 2013 at 23:00:07 UTC, H. S. Teoh wrote:
On Wed, Sep 04, 2013 at 02:14:26PM -0700, Ali Çehreli wrote:
On 09/04/2013 01:46 PM, Adam D. Ruppe wrote:
D does not support implicit struct construction.
That's what I knew.
Interestingly though, it *does* support it for functions taking
classes:
class Foo {
this(int i) {}
}
void foo(Foo f...) {}
void main() {
foo(10);
}
WHAT? :) It even new's one?
But it works only for the ellipsis.
I wonder why the discrepancy...
[...]
Whoa. I never knew about this! It's ... I don't know what to say. It
seems to be a cool feature, but it's also ... so scary. Implicit
new's just leaves a lump in my throat. Is this an actual, intentional
feature??!
T
It, in theory, doesn't allocate memory:
An implementation may construct the object or array instance on the
stack. Therefore, it is an error to refer to that instance after the
variadic function has returned
That's even more scary. So the object implicitly constructed in this way
is put on the *stack* instead of the heap, and becomes invalid after the
function returns? That's just a minefield of pitfalls waiting to
happen...
[...]
Hmm. I experimented with this feature, and found some interesting
quirks:
void foo(Foo f...) {...}
can only be called with the same arguments as Foo's ctor, and 'f' inside
the function body refers to the *single* class instance implicitly
constructed. The object is actually allocated on the heap, even though
the class reference is on the stack (perfectly normal). So this syntax
appears to be some kind of surrogate ctor syntax, in which foo() acts as
a surrogate ctor, getting the constructed object as a parameter and
possibly modifying it or returning something else in its place.
I can see where this might be useful, but I'm confused by the choice of
syntax. This isn't a true variadic function at all; it's a ctor wrapper?
Why was this syntax chosen?
I'm really puzzled now.
T
--
One disk to rule them all, One disk to find them. One disk to bring them all
and in the darkness grind them. In the Land of Redmond where the shadows lie.
-- The Silicon Valley Tarot
Re: template instantiation --- having trouble therewith
On Tuesday, 3 September 2013 at 17:25:12 UTC, Manfred Nowak wrote:
Carl Sturtivant wrote:
Writing muddle!(int,int)
[...]
gives the same error message.
Not entirely true:
template muddle( T, U...){
alias T delegate( U) Dptr;
auto muddle1( T, U...)( Dptr f) {
return f; //or make another delegate in real code
}
alias muddle1!( T, U) muddle;
}
unittest {
import std.stdio;
int x = 3;
int scale( int s) { return x * s; }
auto f= muddle!( int, int)( scale);
writeln( f(7));
}
Can you point me at some documentation that explains this
behavior?
Re: template instantiation --- having trouble therewith
On Tuesday, 3 September 2013 at 13:42:44 UTC, Manfred Nowak wrote: Carl Sturtivant wrote: No it isn't according to dmd. dmd does not express this. according to p1.d(15): Error: [...] dmd cannot deduce that `Dptr!(T, U)' might be equal to `int delegate(int)' Indeed, dmd doesn't know the equivalence, and therefore won't compile my code.
Re: template instantiation --- having trouble therewith
On Tuesday, 3 September 2013 at 21:52:58 UTC, Manfred Nowak wrote:
Carl Sturtivant wrote:
is supposed to transform one delegate into another
Then please declare the template parameters to be delegates:
U muddle( T, U)( T f) {
uint g( int fp){
return cast(uint)( 5* f( fp));
}
auto gP= g;
return gP;
}
unittest {
import std.stdio;
int x = 3;
int scale( int s) { return x * s; }
auto f= muddle!( int delegate( int), uint delegate( int))(
scale);
writeln( f(7));
}
But I want some inference. In the real code the relevant
delegates will have lots of long messy signatures that have
already been declared.
And in your example above, I want the arguments of the delegates
in general to be a type tuple, because any delegate may be passed.
Re: template instantiation --- having trouble therewith
On Tuesday, 3 September 2013 at 17:25:12 UTC, Manfred Nowak wrote:
Carl Sturtivant wrote:
Writing muddle!(int,int)
[...]
gives the same error message.
Not entirely true:
template muddle( T, U...){
alias T delegate( U) Dptr;
auto muddle1( T, U...)( Dptr f) {
return f; //or make another delegate in real code
}
alias muddle1!( T, U) muddle;
}
unittest {
import std.stdio;
int x = 3;
int scale( int s) { return x * s; }
auto f= muddle!( int, int)( scale);
writeln( f(7));
}
-manfred
This technique does what I want if there's a single parameter to
the delegate. I'll explore from here; thanks for all the examples.
Carl.
Re: PyD status and tutorials
On Saturday, 31 August 2013 at 15:44:03 UTC, Russel Winder wrote: On Sat, 2013-08-31 at 12:56 +0200, Larry wrote: Ok python3-dev was missing. Are you using Python 3.3? Are you using SCons or Tup for the build? I just tried the SCons build OOTB and it fails to build PyD with DMD :-( Ehh, yeah. I gave up on build systems a while back because it made it unnecessarily complicated to set up test vms for more exotic systems. Now we use python setup.py [build|install] because python's always there. OP has that right. Since I've been out of the loop for a while, can gdc build shared libraries yet? That's what OP's build command is trying to do.
