Re: function with is own lamda expression
On 11/30/2013 05:53 PM, bioinfornatics wrote:
> I write a function with Lambda expression + safe + pure wich do same
> (close) as countUntil
>
> http://www.dpaste.dzfl.pl/63d03540
>
> but i fail to use lambda expression into my function. I try by two way
> - alias this pred … (to get a default lambda)
> - function(…) pred
>
> both way i fail, could you take a look to code please.
>
> Goal is to get a pure and safe function
>
> thanks
The obvious problem in the code is the fact that although the intent and
the lambda expression itself is written to take two parameters, the
lambda is called without any arguments:
1) The default lambda takes two parameters:
auto search( alias pred = (a,b) => a == b, R,T,S=T)( const ref R
toSearch, in T toMatch ) pure
2) and the provided lambda takes two parameters:
assert( arrStruct.search!( (a,b) => a.id == b )( 8uL ) == 7 );
3) However, the call itself takes no arguments:
if( pred() ){
So, I would start with that call to debug and pass the two arguments
that are appropriate (toSearch.front and toMatch, perhaps?)
Ali
Re: alias this leads to compilation error in one of two similar contexts
On 11/30/2013 02:18 PM, Carl Sturtivant wrote:
The following is boiled down from a real world context. I'm using dmd
2.064.2 Windows. Can someone please explain what's going on.
struct my_integer {
int val = 99;
alias val this;
//this( int n) { val = n; }
}
struct blah {
my_integer Integer;
this( int n) { Integer = n; }
ref blah opAssign( int n) { Integer = n; return this; }
}
The constructor in blah does not compile unless the constructor in
my_integer is uncommented. Yet the opAssign function in blah compiles
just fine.
The error message is
Error: cannot implicitly convert expression (n) of type int to my_integer
and the line causing it is blah's constructor.
This behavior did not exist with dmd 2.063.2 (Windows) --- I reverted to
check this.
At least the discrepancy warrants a bug report:
https://d.puremagic.com/issues/
Ali
opApply and lazy
It's impossible to pass lazy value to foreach cycle by opApply. Bug, feature or my fault? http://dpaste.dzfl.pl/6f445ce9
Re: std.math.atan2 -- range of output
On 30/11/13 18:44, Joseph Rushton Wakeling wrote: I ask because I ran into this while trying to create a unittest for the case (-1.0) ^^ complex(1.0, 1.0); ... as part of the work I'm doing on https://d.puremagic.com/issues/show_bug.cgi?id=11652 although deeper investigation shows that this case the fault is not with atan2: the problem is that this number evaluates to -0.0432139 - 2.34263e-21i i.e. the imaginary part evaluates to something very slightly imaginary, which in turn leads to an argument that is _almost_ -PI. Still, I'm curious about the rationale behind the behaviour of atan2.
Re: function with is own lamda expression
On Sunday, 1 December 2013 at 08:22:41 UTC, Ali Çehreli wrote:
On 11/30/2013 05:53 PM, bioinfornatics wrote:
> I write a function with Lambda expression + safe + pure wich
do same
> (close) as countUntil
>
> http://www.dpaste.dzfl.pl/63d03540
>
> but i fail to use lambda expression into my function. I try
by two way
> - alias this pred … (to get a default lambda)
> - function(…) pred
>
> both way i fail, could you take a look to code please.
>
> Goal is to get a pure and safe function
>
> thanks
The obvious problem in the code is the fact that although the
intent and the lambda expression itself is written to take two
parameters, the lambda is called without any arguments:
1) The default lambda takes two parameters:
auto search( alias pred = (a,b) => a == b, R,T,S=T)( const
ref R toSearch, in T toMatch ) pure
2) and the provided lambda takes two parameters:
assert( arrStruct.search!( (a,b) => a.id == b )( 8uL ) == 7 );
3) However, the call itself takes no arguments:
if( pred() ){
So, I would start with that call to debug and pass the two
arguments that are appropriate (toSearch.front and toMatch,
perhaps?)
Ali
Thanks Ali,
that works now, i was close. http://www.dpaste.dzfl.pl/63d03540
Re: Deimos rules?
Le 13/11/2013 23:01, Xavier Bigand a écrit : I work on XCB integration, so I think that I can add bindings in deimos. C headers are translated to d modules by using DStep or manually? If manually need I respect some syntactical rules? I think it's enough mature to be integrated to deimos. It builds fine but I have some issues with XCB, the official sample written in C doesn't work too, so the bindings seems correct. You can fork it from : https://github.com/D-Quick/XCB
Template condition triggers compiler error?
This code compiles:
template gc_free(T) {
static if (is(T : U*, U) || is(T : U[], U))
alias Type = T;
else
alias Type = T*;
void gc_free(Type data) {
import core.memory : GC;
static if (is(Type : U[], U)) {
GC.free(data.ptr);
GC.minimize();
} else {
GC.free(data);
}
data = null;
}
}
But with a template condition it triggers compiler errors:
template gc_free(T) if (!is(T == class)) {
static if (is(T : U*, U) || is(T : U[], U))
alias Type = T;
else
alias Type = T*;
void gc_free(Type data) {
import core.memory : GC;
static if (is(Type : U[], U)) {
GC.free(data.ptr);
GC.minimize();
} else {
GC.free(data);
}
data = null;
}
}
Errors:
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(177): Error: template instance share.share!(A) error
instantiating
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(197): Error: template instance share.share!(A) error
instantiating
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
It seems to work on Linux with 64 bit, but it fails on Windows 7
32 bit.
Bug, feature or my fault?
Rest
Hi, i just got some progress in my first D project and wanted to know if i made some basic mistakes and what could have been done in an more elegant way. I'm open for every advice i get. The project is basicly a copy of javas jax-rs but in a very very early state :). I know my Httprequest and Httpresponse classes aren't really existent but they weren't really my focus. just wanted to try out D s compiletime reflection. http://www.dpaste.dzfl.pl/31ca9491
Re: Rest
yes i have seen it. But i wanted to try it out my self. And thought it's a good project to learn D.
Re: Rest
Have you seen vibe.d REST module? It does exactly that - abuses D reflection for REStful HTTP API generation. code - https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/rest.d example - https://github.com/rejectedsoftware/vibe.d/blob/master/examples/rest/source/app.d
Re: Rest
On Sunday, 1 December 2013 at 18:24:58 UTC, guest wrote: yes i have seen it. But i wanted to try it out my self. And thought it's a good project to learn D. Well, you need to be a bit more precise about kind of feedback you want to get than :) It is pretty large topic to talk about.
Re: Rest
just wanted to know if something in my code is really bad or could be solved in more elegant way. Basicly things which people with more experience in D see on their first view of my code.
Re: How to convert these constructs to D?
On Sunday, 1 December 2013 at 03:20:49 UTC, Craig Dillabaugh
wrote:
On Saturday, 30 November 2013 at 14:53:35 UTC, Gary Willoughby
wrote:
I'm porting some C headers and wondered how would i convert
the following to D:
#define pthread_self() GetCurrentThreadId()
#define pthread_handler_t void * __cdecl
typedef void * (__cdecl *pthread_handler)(void *);
#define set_timespec_nsec(ABSTIME,NSEC) { \
GetSystemTimeAsFileTime(&((ABSTIME).tv.ft)); \
(ABSTIME).tv.i64+= (__int64)(NSEC)/100; \
(ABSTIME).max_timeout_msec= (long)((NSEC)/100); \
}
Maybe you have already solved all your problems, but have you
tried DStep with this header? I used it on FFTW3, which is
basically one GIANT C 100 line macro, and it 'seems' to have
done a great job on that. However, in other cases it just seems
to have dropped some defines altogether, so your mileage may
vary.
Craig
To be honest i didn't. The last time i tried DStep i had problems
with compilation. I'll take another look though. I'm basically
porting all the mysql-client headers which i thought would be
pretty straight forward but it's taking a little more thought
than i anticipated.
Re: How to convert these constructs to D?
I'm basically porting all the mysql-client headers which i thought would be pretty straight forward but it's taking a little more thought than i anticipated. Can I ask why? And the part of code you are asking is from pthread headers not from mysql.
Re: non-determinant object lifetime and memory management
On Sunday, 1 December 2013 at 02:29:42 UTC, bioinfornatics wrote: On Saturday, 30 November 2013 at 08:35:23 UTC, Frustrated wrote: I need to pass around some objects(specifically int[]) that may be used by several other objects at the same time. While I could clone these and free them when the parent object is done this wastes memory for no real reason except ease of use. Since many objects may contain a ptr to the array, what would be the best way to deal with deallocating them? I could wrap the array in a collection an use ARC but is there a better way? Is there something in std.allocators that can help? (Should be obvious that I'm trying to avoid the GC) Why you do not use one of this way: - const ref int[]… into function parameter - using shared/synchronized and ref to array It would seem if I am going to use some way it needs to be consistent. The first case would require creating []'s outside of the function which then doesn't solve the original problem. I'm not sure how the second case solves anything?
Re: How to convert these constructs to D?
On Sunday, 1 December 2013 at 18:51:51 UTC, Gary Willoughby wrote:
On Sunday, 1 December 2013 at 03:20:49 UTC, Craig Dillabaugh
wrote:
On Saturday, 30 November 2013 at 14:53:35 UTC, Gary Willoughby
wrote:
I'm porting some C headers and wondered how would i convert
the following to D:
#define pthread_self() GetCurrentThreadId()
#define pthread_handler_t void * __cdecl
typedef void * (__cdecl *pthread_handler)(void *);
#define set_timespec_nsec(ABSTIME,NSEC) { \
GetSystemTimeAsFileTime(&((ABSTIME).tv.ft)); \
(ABSTIME).tv.i64+= (__int64)(NSEC)/100; \
(ABSTIME).max_timeout_msec= (long)((NSEC)/100); \
}
Maybe you have already solved all your problems, but have you
tried DStep with this header? I used it on FFTW3, which is
basically one GIANT C 100 line macro, and it 'seems' to have
done a great job on that. However, in other cases it just
seems to have dropped some defines altogether, so your mileage
may vary.
Craig
To be honest i didn't. The last time i tried DStep i had
problems with compilation. I'll take another look though. I'm
basically porting all the mysql-client headers which i thought
would be pretty straight forward but it's taking a little more
thought than i anticipated.
I think you end up with a bit nicer interface if you hand role
your own, but at least DStep can take care of a good bit of the
grunt work for you. I had some trouble getting it running the
first time (mostly my own fault), but am now glad I made the
effort.
Re: Template condition triggers compiler error?
On Sunday, 1 December 2013 at 16:07:18 UTC, Namespace wrote:
This code compiles:
template gc_free(T) {
static if (is(T : U*, U) || is(T : U[], U))
alias Type = T;
else
alias Type = T*;
void gc_free(Type data) {
import core.memory : GC;
static if (is(Type : U[], U)) {
GC.free(data.ptr);
GC.minimize();
} else {
GC.free(data);
}
data = null;
}
}
But with a template condition it triggers compiler errors:
template gc_free(T) if (!is(T == class)) {
static if (is(T : U*, U) || is(T : U[], U))
alias Type = T;
else
alias Type = T*;
void gc_free(Type data) {
import core.memory : GC;
static if (is(Type : U[], U)) {
GC.free(data.ptr);
GC.minimize();
} else {
GC.free(data);
}
data = null;
}
}
Errors:
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(177): Error: template instance share.share!(A) error
instantiating
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(197): Error: template instance share.share!(A) error
instantiating
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
share.d(10): Error: undefined identifier Type
It seems to work on Linux with 64 bit, but it fails on Windows
7 32 bit.
Bug, feature or my fault?
Compiler bug.
https://d.puremagic.com/issues/show_bug.cgi?id=11662
Kenji Hara
Re: alias this leads to compilation error in one of two similar contexts
On Saturday, 30 November 2013 at 22:28:14 UTC, Carl Sturtivant
wrote:
I just confirmed the same behavior on Ubuntu amd64. dmd 2.063.2
compiles the example and dmd 2.064.2 produces the same error as
the Windows 32 bit version.
This is intended behavior change from 2.064.
http://dlang.org/class#field-init
struct my_integer {
int val = 99;
alias val this;
}
void test() {
//my_interger num = 1; // NG
my_interger num = my_interger(1); // OK
// 'alias this' has no effect for object initialization
}
struct blah {
my_integer num;
this(int n) {
//num = n; // also NG, my_integer cannot *initialize* by
int value
num = my_interger(n); // OK
}
}
Kenji Hara
enum value vs. immutable
I was reading the enum page of Ali Çehreli's (excellent) D book (http://ddili.org/ders/d.en/enum.html), and I'm confused by an enum value (not enum type), such as enum secondsPerDay = 60 * 60 * 24; In that situation I would have used an immutable variable. Is there any reason to prefer enum vs. immutable when defining constants?
Re: enum value vs. immutable
On 12/01/2013 09:57 PM, CJS wrote: > I was reading the enum page of Ali Çehreli's (excellent) D book > (http://ddili.org/ders/d.en/enum.html), and I'm confused by an enum > value (not enum type), such as > enum secondsPerDay = 60 * 60 * 24; > In that situation I would have used an immutable variable. Is there any > reason to prefer enum vs. immutable when defining constants? After realizing the other day that even 'static const' can be used for template instantiations, I am not sure myself anymore. :) Simple rules are great. I wanted to accept the following guidelines, none of which are clear cut: 1) Prefer enum first because enum values can be used for template instantiations. 2) Prefer immutable next because it provides stronger guarantees. 3) Prefer const last as it erases immutable attribute if present. (We can't know just by looking at a reference to const whether the original value has been immutable or mutable.) The first item needs qualification: Do not use enum for arrays and associative arrays, because enum is like copy+pasting the definition everywhere the enum is used. It is expensive to initialize arrays and AAs. The second item needs qualification: immutable is not just a stronger const, it is a requirement, a burden. It requires that the object is deeply immutable and it is also a burden on types: They cannot contain mutable references. (This affects future development; you can't add mutable references to a type that has already been used as immutable somewhere in the code.) So, it is not a clear cut decision because it depends on the type as well. For example, these days I use const even for manifest constants like 60 * 60 * 24 because for all practical purposes it is a manifest constant! This must be new in D; I don't think it worked that way but it works even with CTFE now. Additionally const is shorter to type and easier on the eyes. :) Ali
Re: enum value vs. immutable
On Monday, 2 December 2013 at 07:31:56 UTC, Sergei Nosov wrote: On Monday, 2 December 2013 at 05:57:33 UTC, CJS wrote: I was reading the enum page of Ali Çehreli's (excellent) D book (http://ddili.org/ders/d.en/enum.html), and I'm confused by an enum value (not enum type), such as enum secondsPerDay = 60 * 60 * 24; In that situation I would have used an immutable variable. Is there any reason to prefer enum vs. immutable when defining constants? enum is a compile-time constant and an immutable variable is not. As an example, in order to create a enum variable you have to know it's value at compile time, e.g. you can't read it from file. On the contrary, you can read a string from file and string is the same thing as immutable(char) in D. Typo - "the string is the same thing as immutable(char)[]" in D (note the rectangular braces)
Re: enum value vs. immutable
On Monday, 2 December 2013 at 05:57:33 UTC, CJS wrote: I was reading the enum page of Ali Çehreli's (excellent) D book (http://ddili.org/ders/d.en/enum.html), and I'm confused by an enum value (not enum type), such as enum secondsPerDay = 60 * 60 * 24; In that situation I would have used an immutable variable. Is there any reason to prefer enum vs. immutable when defining constants? enum is a compile-time constant and an immutable variable is not. As an example, in order to create a enum variable you have to know it's value at compile time, e.g. you can't read it from file. On the contrary, you can read a string from file and string is the same thing as immutable(char) in D.
Re: enum value vs. immutable
On Monday, 2 December 2013 at 07:27:25 UTC, Ali Çehreli wrote:
On 12/01/2013 09:57 PM, CJS wrote:
> I was reading the enum page of Ali Çehreli's (excellent) D
book
> (http://ddili.org/ders/d.en/enum.html), and I'm confused by
an enum
> value (not enum type), such as
> enum secondsPerDay = 60 * 60 * 24;
> In that situation I would have used an immutable variable. Is
there any
> reason to prefer enum vs. immutable when defining constants?
After realizing the other day that even 'static const' can be
used for template instantiations, I am not sure myself anymore.
:)
Simple rules are great. I wanted to accept the following
guidelines, none of which are clear cut:
1) Prefer enum first because enum values can be used for
template instantiations.
You can instatiate templates not only with enums. Main pro for
enums is that they are CT values.
3) Prefer const last as it erases immutable attribute if
present. (We can't know just by looking at a reference to const
whether the original value has been immutable or mutable.)
It is interesting to know where such advices come from. Const in
D is useless except as as parameter qualifier, method qualifier,
tool to alias const data and non-const data and as qualifier of
some field - member of aggregate.
Writing code like
const int i = SOME_VALUE;
is loosing advantages of immutable or enum while gaining nothing
in return.
It is C++ism like follwoing code:
struct S { public: this(type){} ... }
or
static Type t; // in module scope
