Re: can clone a thread?
D is cross-platform, so to have a wrapper for fork() would
mean to get it working on Windows, too.
std.process, can must use fork() of course, since it is the
way to spawn a child process on Posix systems. fork() doesn't
clone a thread, but a whole process. So there is no issue
with the GC, as it will be cloned as well. Until Posix threads
were introduced, it was common to create threads using
fork(), so it probably works ok for you. Maybe we can find a
better solution though if you tell us some more.
For example this exists in D:
static this()
{
// Initialize TLS variables
}
That is a module constructor that is run once for each new
Thread. You could prepare your TLS variables there as a copy
of global data or other function calls.
If you really need an automated copy of all TLS variables for
a new thread the situation looks dim I guess :p
No, i think fork or something similar is the way i prefer to go.
I'm working on a simple top-down parser, so i save all the data
references in the context of the function and at the end of it i
create the syntax tree object with all his childrens. So i have
the already allocated objects in the tls and the info on the
realtionships of these objects plus the parser state in the call
stack. I want to duplicate the parser because i want all the
possible syntax trees as a result and when the tokenizer will
find in the input two or more possible tokens, it must fork and
return for each thread one token from the possible ones. At the
end if one or more threads made to the end, each thread copy his
syntax tree on a shared array and the main thread then can work
on the results.
Another way to solve this is to move all the info from the call
stack to a stack managed by me, have a standard procedure that
fills the stack. When i must duplicate the thread i can create a
new one, make a deep copy of the objects in the stack and the
stack itself, then call the standard procedure again. But i think
this is a bottom-up parser and a major change in the application
design.
For now i will stick with fork, if in the future a similar
function is implemented in core.thread, i will use it.
Re: Python calling D
On Wednesday, 11 December 2013 at 05:30:49 UTC, CJS wrote: I'd like to use cython to wrap a D library. It's possible to do this with a statically compiled C library, but it fails when I try with a statically compiled D library. Any suggestions on how to do this successfully? I'm not Cython guy, but as I know, Cython generates C code, right? Then probably at first you should learn how to call D functions from C side. I don't know how to do it correctly. It's easily to call those D functions which don't use 'new' operation and garbage collection (explicitly or implicitly). But when they do that, I get segmentation fault.
Re: can clone a thread?
Am Wed, 11 Dec 2013 09:10:09 +0100 schrieb Gianni Pisetta pisetta.gia...@alice.it: No, i think fork or something similar is the way i prefer to go. I'm working on a simple top-down parser, so i save all the data references in the context of the function and at the end of it i create the syntax tree object with all his childrens. So i have the already allocated objects in the tls and the info on the realtionships of these objects plus the parser state in the call stack. I want to duplicate the parser because i want all the possible syntax trees as a result and when the tokenizer will find in the input two or more possible tokens, it must fork and return for each thread one token from the possible ones. At the end if one or more threads made to the end, each thread copy his syntax tree on a shared array and the main thread then can work on the results. Another way to solve this is to move all the info from the call stack to a stack managed by me, have a standard procedure that fills the stack. When i must duplicate the thread i can create a new one, make a deep copy of the objects in the stack and the stack itself, then call the standard procedure again. But i think this is a bottom-up parser and a major change in the application design. For now i will stick with fork, if in the future a similar function is implemented in core.thread, i will use it. Alright, fork is optimized for this kind of stuff and it should work fine. Personally I would likely have tried a manged stack instead of cloning the whole application. How do you write back the results from the child processes? Do you use pipes or shared memory? -- Marco
Win Headers
Are there complete windows headers and if yes where can i find them and will they work for 64bit?
Re: Ranges require GC?
Am Wed, 11 Dec 2013 08:20:19 +0100 schrieb Frustrated c1514...@drdrb.com: On Wednesday, 11 December 2013 at 02:37:32 UTC, Jonathan M Davis wrote: On Wednesday, December 11, 2013 03:09:52 Frustrated wrote: But surely memory gets allocated in some way? In Programming in D: For example filter(), which chooses elements that are greater than 10 in the following code, actually returns a range object, not an array: But if filter is a range and returns an object then how is that object allocated? That's just a wording issue. It means object in the wider sense, not instance of a class. I'm trying to avoid the GC so knowing whether or not ranges will use the heap is extremely important. I guess that is where the @nogc attribute that everyone talks about would come in very handy. Correct. -- Marco
Re: Swapping nibbles range style
Am Wed, 11 Dec 2013 07:19:41 +0100
schrieb Volcz vo...@kth.se:
Are there any obvious difference between the three solutions I
have received? They all to work the same to me.
I hope they all work the same! Depending on your background
you just might prefer one style over the other.
As an example take me. I like high efficiency so I look at the
version with
src.chunks(2).map!((a) {
auto a1 = a.front();
a.popFront();
return format(%s%s, a.front(), a1);
} )
and notice the format() function, which looks overkill to me
for a task of swapping two bytes. Then there is chunks(),
which will decode the UTF-8 string in src, which I don't need,
since there are no multi-byte characters in src. The same is
true for
return range.chunks(2).map!(
chunk = chunk.cycle.dropOne.takeExactly(2)
).joiner;
and
return s.chunks(2).map!(
c = [cast(char)c.dropOne.front, cast(char)c.front]
).join;
So I would use the second version offered by bearophile:
auto result = new char[s.length];
foreach (immutable i, ref c; result)
c = s[i + (i 1 ? -1 : 1)];
return result;
I can easily reason about it from looking at it. It makes one
allocation new char[s.length] and does no UTF-8 decoding.
--
Marco
Re: std.file.dirEntries unsorted
Am Wed, 11 Dec 2013 08:00:27 +0100 schrieb Jesse Phillips jesse.k.phillip...@gmail.com: It should only be documented. In my experience processing files don't need a particular order and sorting may not be needed by name. Returning a sorted directory is difficult to define, should directories come first or be mixed with the files. Is uppercase grouped together? Does A come before a. Should the extension be included or postponed for later. I think sorting should be explicit. Does 2.jpg come after 10.jpg ? What's the order of Arabic-Indic one ۱ compared to Latin one 1 ? And so on and so forth. -- Marco
Re: Performance of ranges verses direct
Am Wed, 11 Dec 2013 08:29:38 +0100 schrieb Frustrated c1514...@drdrb.com: Has anyone done any work on comparing the performance of ranges vs using direct straightforward code(optimized in the sense of the way ranges work but by hand). e.g., How does filter compare to a simple loop over the elements and comparing it. How does a a chain of UFCS compare to doing the same in a simple loop. Just use hand written loops if you are worried about this or benchmark on a per case basis. There is no one fits all answer. Not all code executes a million times per second though, so feel free to use them now and then where concise code is regarded higher than premature optimization. ;) -- Marco
Re: Type inference and overloaded functions
On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli wrote: On 12/10/2013 04:37 PM, Namespace wrote: int[] arr2 = [7, 8, 9]s; assert(is(typeof(arr2) == int[3])); That looks very confusing. The left-hand side looks like a slice, which I can append elements to but its type is a static array? Ali That is intended (but can be discussed of course). It was often desired to write int[$] arr = [1, 2, 3]; to auto-determine the dimension. And my change does something like that: if you assign a static array to a slice, the dimension is auto-determined and the type is adapted.
Re: can clone a thread?
On Wednesday, 11 December 2013 at 08:54:18 UTC, Marco Leise wrote: Am Wed, 11 Dec 2013 09:10:09 +0100 schrieb Gianni Pisetta pisetta.gia...@alice.it: No, i think fork or something similar is the way i prefer to go. I'm working on a simple top-down parser, so i save all the data references in the context of the function and at the end of it i create the syntax tree object with all his childrens. So i have the already allocated objects in the tls and the info on the realtionships of these objects plus the parser state in the call stack. I want to duplicate the parser because i want all the possible syntax trees as a result and when the tokenizer will find in the input two or more possible tokens, it must fork and return for each thread one token from the possible ones. At the end if one or more threads made to the end, each thread copy his syntax tree on a shared array and the main thread then can work on the results. Another way to solve this is to move all the info from the call stack to a stack managed by me, have a standard procedure that fills the stack. When i must duplicate the thread i can create a new one, make a deep copy of the objects in the stack and the stack itself, then call the standard procedure again. But i think this is a bottom-up parser and a major change in the application design. For now i will stick with fork, if in the future a similar function is implemented in core.thread, i will use it. Alright, fork is optimized for this kind of stuff and it should work fine. Personally I would likely have tried a manged stack instead of cloning the whole application. How do you write back the results from the child processes? Do you use pipes or shared memory? I also like the managed stack idea, but i think the main problem with that is that it is harder to understand what's going on when you have to debug. I'm not at the point yet of passing the results to the main thread, but i think at the end i will make the entire tree immutable(or maybe already create it with immutable) and add the reference to a shared array or use a message passing pattern like the one in std.concurrency. Gianni Pisetta
Re: Template resolution and interfaces
On Tuesday, 10 December 2013 at 17:50:45 UTC, Torje Digernes
wrote:
http://pastie.org/8542555
Compositing an class via curry fails when I try to use
interfaces.
Guessing that this is due to when classes are validated for
interface implementation and when templates are instantiated.
I thought this was a cool optional way to build/composite
classes
instead of wrappers. Don't think it has inherent advantages
(except that trivial wrappers look silly), just another way to
do
it. Any chance I can do this anytime soon? Or already by writing
somewhat smarter?
Your code creates an alias, which only exists at compile-time but
not at run-time. The compiler error interface function 'void
mpriority()' is not implemented is correct.
A naive implementation is straightforward:
void mpriority() { priority(myData); }
Why do you want to use curry?
Re: Performance of ranges verses direct
On Wednesday, 11 December 2013 at 07:29:39 UTC, Frustrated wrote: Has anyone done any work on comparing the performance of ranges vs using direct straightforward code(optimized in the sense of the way ranges work but by hand). e.g., How does filter compare to a simple loop over the elements and comparing it. How does a a chain of UFCS compare to doing the same in a simple loop. In my very unscientific experiments: range based, functional style D code runs about 75-100% speed of the equivalent explicit iterative version. A lot of the performance loss is down to missed optimisations, in particular inlining. gdc/ldc are good at this, dmd not so good so you'll likely see bigger performance gaps with dmd than the other compilers. General advice: use ranges, std.range and std.algorithm wherever possible. Profile the resulting code and write out the hotspots in an imperative style to see if you can squeeze out some extra speed.
universal databade connector as jdbc
Hi, Little question, I'm looking a jdbc like in D ? Does this exists ? Thanks
Re: universal databade connector as jdbc
On Wednesday, 11 December 2013 at 10:49:43 UTC, bioinfornatics wrote: Hi, Little question, I'm looking a jdbc like in D ? Does this exists ? Thanks https://github.com/buggins/ddbc - see readme for more info.
Re: universal databade connector as jdbc
On Wednesday, 11 December 2013 at 11:00:40 UTC, QAston wrote: On Wednesday, 11 December 2013 at 10:49:43 UTC, bioinfornatics wrote: Hi, Little question, I'm looking a jdbc like in D ? Does this exists ? Thanks https://github.com/buggins/ddbc - see readme for more info. Cool thanks, i will take a look. If in more it is able to run at comppile time that could be awesome
Re: Swapping nibbles range style
Marco Leise: return s.chunks(2).map!( c = [cast(char)c.dropOne.front, cast(char)c.front] ).join; So I would use the second version offered by bearophile: auto result = new char[s.length]; foreach (immutable i, ref c; result) c = s[i + (i 1 ? -1 : 1)]; return result; I can easily reason about it from looking at it. It makes one allocation new char[s.length] and does no UTF-8 decoding. But the first version with dropOne and two fronts is for me simper to see as correct, while in the second code I need a bit of thinking to prove there are no out of bounds accesses. Perhaps for/foreach are becoming a code smell, they are becoming an optimization over the more common and safer functional code (or an alternative solution where the functional code is a problem). To avoid the conditional (I have not benchmarked them): c = s[i + (2 * !(i 1) - 1)]; Bye, bearophile
Re: Python calling D
On Wednesday, 11 December 2013 at 05:30:49 UTC, CJS wrote: I'd like to use cython to wrap a D library. It's possible to do this with a statically compiled C library, but it fails when I try with a statically compiled D library. Any suggestions on how to do this successfully? Have you had a look at this: http://pyd.dsource.org/ https://github.com/dansanduleac/pyd
Re: Python calling D
On Wednesday, 11 December 2013 at 11:41:11 UTC, Chris wrote: On Wednesday, 11 December 2013 at 05:30:49 UTC, CJS wrote: I'd like to use cython to wrap a D library. It's possible to do this with a statically compiled C library, but it fails when I try with a statically compiled D library. Any suggestions on how to do this successfully? Have you had a look at this: http://pyd.dsource.org/ https://github.com/dansanduleac/pyd both of those are out of date, this is where development is now: https://bitbucket.org/ariovistus/pyd
Re: Python calling D
On Wednesday, 11 December 2013 at 05:30:49 UTC, CJS wrote: I'd like to use cython to wrap a D library. It's possible to do this with a statically compiled C library, but it fails when I try with a statically compiled D library. Any suggestions on how to do this successfully? 1) have you declared the functions you want to call with extern(C)? 2) you will need to compile the D code as a shared library. 3) you will need to call rt_init / rt_term to start / stop the runtime in order to use some features of D. There are problems with the runtime when using multiple D shared libraries, so it's best to link everything you need as a single shared lib.
Re: universal databade connector as jdbc
On 12/11/13 8:05 AM, bioinfornatics wrote: On Wednesday, 11 December 2013 at 11:00:40 UTC, QAston wrote: On Wednesday, 11 December 2013 at 10:49:43 UTC, bioinfornatics wrote: Hi, Little question, I'm looking a jdbc like in D ? Does this exists ? Thanks https://github.com/buggins/ddbc - see readme for more info. Cool thanks, i will take a look. If in more it is able to run at comppile time that could be awesome I don't think you will ever be able to execute an SQL query at compile time...
Re: Type inference and overloaded functions
On Wednesday, 11 December 2013 at 09:49:13 UTC, Namespace wrote: On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli wrote: On 12/10/2013 04:37 PM, Namespace wrote: int[] arr2 = [7, 8, 9]s; assert(is(typeof(arr2) == int[3])); That looks very confusing. The left-hand side looks like a slice, which I can append elements to but its type is a static array? Ali That is intended (but can be discussed of course). It was often desired to write int[$] arr = [1, 2, 3]; to auto-determine the dimension. And my change does something like that: if you assign a static array to a slice, the dimension is auto-determined and the type is adapted. I agree with Ali. arr2 says it's a dynamic array but it's not. This could easily lead to errors worse than the class caused by implicit conversions (what's worse than explicitly saying you want an x but getting a y instead?). `int[$]` for this purpose would be acceptable, however. I actually like that idea, personally.
Re: Performance of ranges verses direct
On 11/12/13 11:10, John Colvin wrote:
A lot of the performance loss is down to missed optimisations, in particular
inlining.
Simple example:
foreach(i; iota(0, 10)) { ... }
should be as fast as
foreach(i; 0 .. 10) { ... }
but isn't. I remember Andrei noting that this ought to be easily fixable [*],
but I don't know if that actually happened, because I haven't compared the two
recently.
[* If I recall right, it's achievable by special-casing iota when the increment
is 1, but don't quote me on that.]
General advice: use ranges, std.range and std.algorithm wherever possible.
Profile the resulting code and write out the hotspots in an imperative style to
see if you can squeeze out some extra speed.
Yes -- use ranges as much as possible because the resulting code will be so much
easier to read and maintain. Switching to imperative style is only worth it if
there's a speed problem (read: The speed is unsatisfactory for your use case
and/or inferior to rival programs doing the same thing.).
writeln calls postblits constructor four times before print
Code:
module vector;
import std.stdio;
import std.traits;
struct SVector(size_t dim, T = float)
{
private:
T[dim] _arr;
public:
alias dim dimension;
alias dim size;
this(this)
{
debug(SVector)
writeln(postblit constructor);
}
this(const T[dim] arr)
{
debug(SVector)
writeln(constructor from static array);
_arr = arr;
}
this(ref const T[dim] arr)
{
debug(SVector)
writeln(constructor from ref static array);
_arr = arr;
}
this(const(T)[] arr)
{
debug(SVector)
writeln(constructor from slice);
assert(arr.length == dim);
_arr = arr;
}
ref SVector opAssign(const SVector other)
{
debug(SVector)
writeln(assign other vector);
_arr = other._arr;
return this;
}
ref SVector opAssign(ref const SVector other)
{
debug(SVector)
writeln(assign other ref vector);
_arr = other._arr;
return this;
}
ref SVector opAssign(const T[dim] arr)
{
debug(SVector)
writeln(assign static array);
_arr = arr;
return this;
}
ref SVector opAssign(ref const T[dim] arr)
{
debug(SVector)
writeln(assign ref static array);
_arr = arr;
return this;
}
ref SVector opAssign(const(T)[] arr)
{
debug(SVector)
writeln(assign dynamic array);
assert(arr.length == dim);
_arr = arr;
return this;
}
T[] opSlice()
{
return _arr[];
}
T[] opSlice(size_t begin, size_t end)
{
return _arr[begin..end];
}
const(T)[] opSlice() const
{
return _arr[];
}
const(T)[] opSlice(size_t begin, size_t end) const
{
return _arr[begin..end];
}
T opIndex(size_t i) const
{
return _arr[i];
}
T opIndexAssign(const(T) value, size_t i)
{
return _arr[i] = value;
}
size_t opDollar() const
{
return dim;
}
}
unittest
{
alias float scalar;
alias SVector!(3, scalar) vec;
vec v = [1,2,3];
writeln(v);
}
int main()
{
return 0;
}
This type has simple postblit constructor, but what if it needs
to allocate memory? Simple example is this._arr = _arr.dup if we
would use dynamic array. We have really big overhead here.
By the way, why does writeln able to print this struct? It has no
toString() method and its data is private. How does writeln have
access to it?
Re: std.file.dirEntries unsorted
yes, I agree sorting should be explicit as there's no natural order. However sorting after calling dirEntries is not great as typically one wants to sort within a given directory level and it's too late to sort once all the directory levels are flattened. so how about having an extra argument that takes a lambda (eg binaryFun!ab) in dirEntries, or, having an additional function in std.file that takes such lambda. On Wed, Dec 11, 2013 at 2:31 AM, Marco Leise marco.le...@gmx.de wrote: Am Wed, 11 Dec 2013 08:00:27 +0100 schrieb Jesse Phillips jesse.k.phillip...@gmail.com: It should only be documented. In my experience processing files don't need a particular order and sorting may not be needed by name. Returning a sorted directory is difficult to define, should directories come first or be mixed with the files. Is uppercase grouped together? Does A come before a. Should the extension be included or postponed for later. I think sorting should be explicit. Does 2.jpg come after 10.jpg ? What's the order of Arabic-Indic one ۱ compared to Latin one 1 ? And so on and so forth. -- Marco
Re: Type inference and overloaded functions
On Wednesday, 11 December 2013 at 16:28:39 UTC, Chris Cain wrote: On Wednesday, 11 December 2013 at 09:49:13 UTC, Namespace wrote: On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli wrote: On 12/10/2013 04:37 PM, Namespace wrote: int[] arr2 = [7, 8, 9]s; assert(is(typeof(arr2) == int[3])); That looks very confusing. The left-hand side looks like a slice, which I can append elements to but its type is a static array? Ali That is intended (but can be discussed of course). It was often desired to write int[$] arr = [1, 2, 3]; to auto-determine the dimension. And my change does something like that: if you assign a static array to a slice, the dimension is auto-determined and the type is adapted. I agree with Ali. arr2 says it's a dynamic array but it's not. This could easily lead to errors worse than the class caused by implicit conversions (what's worse than explicitly saying you want an x but getting a y instead?). `int[$]` for this purpose would be acceptable, however. I actually like that idea, personally. Ok, I will change that. ;) And I will try to implement the syntax for int[$].
Re: writeln calls postblits constructor four times before print
FreeSlave:
By the way, why does writeln able to print this struct? It has
no toString() method and its data is private. How does writeln
have access to it?
writeln is able to print structs that don't have a toString, this
is very handy in most cases. When you don't want it, there's
@disable, this doesn't link:
struct Foo {
int x;
//string toString() { return x; }
@disable string toString();
}
void main() {
import std.stdio;
Foo f = Foo(10);
writeln(f);
}
In theory this should be caught by writefln constraint before the
linker. Probably I can turn this into a small enhancement request.
Bye,
bearophile
Re: Template resolution and interfaces
On Wednesday, 11 December 2013 at 10:10:11 UTC, qznc wrote:
On Tuesday, 10 December 2013 at 17:50:45 UTC, Torje Digernes
wrote:
http://pastie.org/8542555
Compositing an class via curry fails when I try to use
interfaces.
Guessing that this is due to when classes are validated for
interface implementation and when templates are instantiated.
I thought this was a cool optional way to build/composite
classes
instead of wrappers. Don't think it has inherent advantages
(except that trivial wrappers look silly), just another way to
do
it. Any chance I can do this anytime soon? Or already by
writing
somewhat smarter?
Your code creates an alias, which only exists at compile-time
but not at run-time. The compiler error interface function
'void mpriority()' is not implemented is correct.
A naive implementation is straightforward:
void mpriority() { priority(myData); }
Why do you want to use curry?
No other reason than that it looks cleaner to me than wrappers. I
tried it because I thought it should work, as I could call it by
that name, but I now see the problem.
Re: writeln calls postblits constructor four times before print
In theory this should be caught by writefln constraint before the linker. Probably I can turn this into a small enhancement request. On the other hand if you care about this it's better for you to open the ER. Bye, bearophile
Re: universal databade connector as jdbc
On Wednesday, 11 December 2013 at 15:34:25 UTC, Ary Borenszweig wrote: On 12/11/13 8:05 AM, bioinfornatics wrote: On Wednesday, 11 December 2013 at 11:00:40 UTC, QAston wrote: On Wednesday, 11 December 2013 at 10:49:43 UTC, bioinfornatics wrote: Hi, Little question, I'm looking a jdbc like in D ? Does this exists ? Thanks https://github.com/buggins/ddbc - see readme for more info. Cool thanks, i will take a look. If in more it is able to run at comppile time that could be awesome I don't think you will ever be able to execute an SQL query at compile time... erf that could to be great to generate structure object at compile time from database schema
Re: Type inference and overloaded functions
On Wednesday, 11 December 2013 at 18:31:20 UTC, Namespace wrote:
On Wednesday, 11 December 2013 at 16:28:39 UTC, Chris Cain
wrote:
On Wednesday, 11 December 2013 at 09:49:13 UTC, Namespace
wrote:
On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli
wrote:
On 12/10/2013 04:37 PM, Namespace wrote:
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[3]));
That looks very confusing. The left-hand side looks like a
slice, which I can append elements to but its type is a
static array?
Ali
That is intended (but can be discussed of course). It was
often desired to write int[$] arr = [1, 2, 3]; to
auto-determine the dimension. And my change does something
like that: if you assign a static array to a slice, the
dimension is auto-determined and the type is adapted.
I agree with Ali. arr2 says it's a dynamic array but it's not.
This could easily lead to errors worse than the class caused
by implicit conversions (what's worse than explicitly saying
you want an x but getting a y instead?). `int[$]` for this
purpose would be acceptable, however. I actually like that
idea, personally.
Ok, I will change that. ;)
And I will try to implement the syntax for int[$].
Was a bit tricky but it works now (even if it may not be perfect):
https://github.com/Dgame/dmd/commits/static_array_literals
Example:
import std.stdio;
void foo(int[3] arr) {
assert(is(typeof(arr) == int[3]));
}
void bar(T)(T arr) {
assert(is(T == int[3]));
}
void quatz(int[] arr) {
assert(is(typeof(arr) == int[]));
}
void main() {
int[] arr0 = [1, 2, 3];
assert(is(typeof(arr0) == int[]));
assert(arr0 == [1, 2, 3]);
int[3] arr1 = [4, 5, 6]s;
assert(is(typeof(arr1) == int[3]));
assert(arr1 == [4, 5, 6]);
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[/*3*/]));
assert(arr2 == [7, 8, 9]);
int[$] arr_a1 = [54, 74, 90, 2010];
assert(is(typeof(arr_a1) == int[4]));
assert(arr_a1 == [54, 74, 90, 2010]);
int[$] arr_a2 = [2010, 90, 74, 54]s;
assert(is(typeof(arr_a2) == int[4]));
assert(arr_a2 == [2010, 90, 74, 54]);
foo([1, 2, 3]);
foo([4, 5, 6]s);
bar([44, 55, 66]s);
auto arr3 = [111, 222, 333];
assert(is(typeof(arr3) == int[]));
auto arr4 = [444, 555, 666]s;
assert(is(typeof(arr4) == int[3]));
quatz([3, 2, 1]);
quatz([8, 7, 6]s);
}
Re: Type inference and overloaded functions
Namespace:
void main() {
int[] arr0 = [1, 2, 3];
assert(is(typeof(arr0) == int[]));
assert(arr0 == [1, 2, 3]);
int[3] arr1 = [4, 5, 6]s;
assert(is(typeof(arr1) == int[3]));
assert(arr1 == [4, 5, 6]);
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[/*3*/]));
assert(arr2 == [7, 8, 9]);
int[$] arr_a1 = [54, 74, 90, 2010];
assert(is(typeof(arr_a1) == int[4]));
assert(arr_a1 == [54, 74, 90, 2010]);
int[$] arr_a2 = [2010, 90, 74, 54]s;
assert(is(typeof(arr_a2) == int[4]));
assert(arr_a2 == [2010, 90, 74, 54]);
foo([1, 2, 3]);
foo([4, 5, 6]s);
bar([44, 55, 66]s);
auto arr3 = [111, 222, 333];
assert(is(typeof(arr3) == int[]));
auto arr4 = [444, 555, 666]s;
assert(is(typeof(arr4) == int[3]));
quatz([3, 2, 1]);
quatz([8, 7, 6]s);
}
Very good, this seems a step forward for D. Are you going to
create two pull requests for dmd? (it will not be accepted before
dmd 2.066).
Is it also guarding against this?
http://d.puremagic.com/issues/show_bug.cgi?id=3849
That in short is this mistake (this currently doesn't give
errors):
string[3] a = [redgreen,blue];
void main() {}
Bye,
bearophile
Re: Type inference and overloaded functions
On Wednesday, 11 December 2013 at 19:51:24 UTC, bearophile wrote:
Namespace:
void main() {
int[] arr0 = [1, 2, 3];
assert(is(typeof(arr0) == int[]));
assert(arr0 == [1, 2, 3]);
int[3] arr1 = [4, 5, 6]s;
assert(is(typeof(arr1) == int[3]));
assert(arr1 == [4, 5, 6]);
int[] arr2 = [7, 8, 9]s;
assert(is(typeof(arr2) == int[/*3*/]));
assert(arr2 == [7, 8, 9]);
int[$] arr_a1 = [54, 74, 90, 2010];
assert(is(typeof(arr_a1) == int[4]));
assert(arr_a1 == [54, 74, 90, 2010]);
int[$] arr_a2 = [2010, 90, 74, 54]s;
assert(is(typeof(arr_a2) == int[4]));
assert(arr_a2 == [2010, 90, 74, 54]);
foo([1, 2, 3]);
foo([4, 5, 6]s);
bar([44, 55, 66]s);
auto arr3 = [111, 222, 333];
assert(is(typeof(arr3) == int[]));
auto arr4 = [444, 555, 666]s;
assert(is(typeof(arr4) == int[3]));
quatz([3, 2, 1]);
quatz([8, 7, 6]s);
}
Very good, this seems a step forward for D. Are you going to
create two pull requests for dmd? (it will not be accepted
before dmd 2.066).
I'm unsure. I'm not that familiar with dmd at all, so maybe some
more advanced guy like Kenji should review my code and create an
own, better pull. What do you mean?
Is it also guarding against this?
http://d.puremagic.com/issues/show_bug.cgi?id=3849
That in short is this mistake (this currently doesn't give
errors):
string[3] a = [redgreen,blue];
void main() {}
Bye,
bearophile
Not yet tested, but I will. :)
Re: std.file.dirEntries unsorted
On Wednesday, 11 December 2013 at 18:34:54 UTC, Timothee Cour wrote: yes, I agree sorting should be explicit as there's no natural order. However sorting after calling dirEntries is not great as typically one wants to sort within a given directory level and it's too late to sort once all the directory levels are flattened. so how about having an extra argument that takes a lambda (eg binaryFun!ab) in dirEntries, or, having an additional function in std.file that takes such lambda. Why is it too late, the file name includes the full path so sorting will still sort sibling directories separately. foreach(de; dirEntries(., SpaneMode.depth).array.sort!((a,b)=a.nameb.name)) ... This seems reasonable for your need, but I didn't test to check the behavior. dirEntries isn't random access so we can't sort it directly. I don't think placing it in dirEntries saves much and it would hide the required array allocation.
Re: Type inference and overloaded functions
Namespace: I'm unsure. I'm not that familiar with dmd at all, so maybe some more advanced guy like Kenji should review my code and create an own, better pull. In that code there is both the [$] and the []s syntaxes. So it's better to submit them as two separated pull requests for the D front-end. Lately Kenji seems a little less active, but he will probably be glad to review your code, fix it, etc. What do you mean? Walter said that dmd 2.065 is meant only as bug-fix release (expecially ICEs) so no significant language enhancement requests will be added in dmd 2.065, and they have to wait for dmd 2.066. But dmd 2.065 is supposed to end quicker, so we will not wait a lot of time. Not yet tested, but I will. :) (Issue 3849 also suggests the ... syntax inside array literals to fulfill a narrow corner case that Walter seems to appreciate. I think it's not an important syntax.) Bye, bearophile
How to handle nested structs when converting C headers?
How to handle nested structs when converting C headers?
In the following snippet i'm currently converting, how would you
convert the nested typed union and structures? Would you declare
them separately then use their types in the Tcl_Obj struct? or is
there a nice way in D to nest them like C?
typedef struct Tcl_Obj {
int refCount; /* When 0 the object will be freed. */
char *bytes;/* This points to the first byte of the
* object's string representation. The array
* must be followed by a null byte (i.e., at
* offset length) but may also contain
* embedded null characters. The array's
* storage is allocated by ckalloc. NULL means
* the string rep is invalid and must be
* regenerated from the internal rep. Clients
* should use Tcl_GetStringFromObj or
* Tcl_GetString to get a pointer to the byte
* array as a readonly value. */
int length; /* The number of bytes at *bytes, not
* including the terminating null. */
Tcl_ObjType *typePtr; /* Denotes the object's type. Always
* corresponds to the type of the object's
* internal rep. NULL indicates the object has
* no internal rep (has no type). */
union { /* The internal representation: */
long longValue; /* - an long integer value. */
double doubleValue; /* - a double-precision floating value. */
VOID *otherValuePtr;/* - another, type-specific value. */
Tcl_WideInt wideValue; /* - a long long value. */
struct {/* - internal rep as two pointers. */
VOID *ptr1;
VOID *ptr2;
} twoPtrValue;
struct {/* - internal rep as a wide int, tightly
* packed fields. */
VOID *ptr; /* Pointer to digits. */
unsigned long value;/* Alloc, used, and signum packed into a
* single word. */
} ptrAndLongRep;
} internalRep;
} Tcl_Obj;
Re: How to handle nested structs when converting C headers?
On Wednesday, 11 December 2013 at 22:45:35 UTC, Gary Willoughby wrote: How to handle nested structs when converting C headers? Nested structs and unions like in your example are supported in D too, same syntax, same effect.
Re: How to handle nested structs when converting C headers?
On Wednesday, 11 December 2013 at 22:54:04 UTC, Adam D. Ruppe
wrote:
Nested structs and unions like in your example are supported in
D too, same syntax, same effect.
Actually, no, not quite the same syntax, I didn't notice the name
at the end of the C one (in D, the anonymous nested structs and
unions are supported).
But almost the same then: make them a nested type with a name
after the struct or union keyword then the member. So
struct TwoPtrValue {/* - internal rep as
two pointers. */
VOID *ptr1;
VOID *ptr2;
}
TwoPtrValue twoPtrValue;
that's how I'd do it
Re: How to handle nested structs when converting C headers?
Adam D. Ruppe: Nested structs and unions like in your example are supported in D too, same syntax, same effect. But don't forget to add to use static struct instad of struct. Bye, bearophile
Re: Type inference and overloaded functions
Namespace: I'm pretty nervous, but here is the first: https://github.com/D-Programming-Language/dmd/pull/2952 Good. Keep in mind that at best it will take a month or more for your patch to be accepted. Also patches that implement basic language features like this pass a stringent process of review, that can be laborious and a bit painful. And even after after all that work there's a certain probability of rejection. So you have to build stamina and accumulate patience :-) (Other kind of patches, like D front-end bug fixes or Phobos improvements are faster and often much less painful). Bye, bearophile
Re: How to handle nested structs when converting C headers?
On Wednesday, 11 December 2013 at 23:12:39 UTC, bearophile wrote: Adam D. Ruppe: Nested structs and unions like in your example are supported in D too, same syntax, same effect. But don't forget to add to use static struct instad of struct. Bye, bearophile Have you got an example because i always get: tcl.d(713): Error: no identifier for declarator twoPtrValue tcl.d(718): Error: no identifier for declarator ptrAndLongRep tcl.d(719): Error: no identifier for declarator internalRep
Re: How to handle nested structs when converting C headers?
On Wednesday, 11 December 2013 at 23:27:57 UTC, Gary Willoughby
wrote:
On Wednesday, 11 December 2013 at 23:12:39 UTC, bearophile
wrote:
Adam D. Ruppe:
Nested structs and unions like in your example are supported
in D too, same syntax, same effect.
But don't forget to add to use static struct instad of
struct.
Bye,
bearophile
Have you got an example because i always get:
tcl.d(713): Error: no identifier for declarator twoPtrValue
tcl.d(718): Error: no identifier for declarator ptrAndLongRep
tcl.d(719): Error: no identifier for declarator internalRep
Like this perhaps:
struct Tcl_Obj
{
int refCount;
char* bytes;
int length;
Tcl_ObjType* typePtr;
static union internalRep
{
c_long longValue;
double doubleValue;
void* otherValuePtr;
Tcl_WideInt wideValue;
static struct twoPtrValue
{
void* ptr1;
void* ptr2;
}
static struct ptrAndLongRep
{
void* ptr;
c_ulong value;
}
}
}
Re: How to handle nested structs when converting C headers?
On Wednesday, 11 December 2013 at 23:35:04 UTC, Gary Willoughby
wrote:
static union internalRep
try
static union InternalRep { /* note the capital letter */
/* snip */
}
InternalRep internalRep;; // still need a decl
Re: How to handle nested structs when converting C headers?
Gary Willoughby: Have you got an example because i always get: tcl.d(713): Error: no identifier for declarator twoPtrValue tcl.d(718): Error: no identifier for declarator ptrAndLongRep tcl.d(719): Error: no identifier for declarator internalRep In D you can't define a struct/union and use it to define an instance on the fly. You have to split definition and use in two parts. Bye, bearophile
Question about function aliases
For example i have some C code like this: typedef void (Tcl_InterpDeleteProc) _ANSI_ARGS_((ClientData clientData, Tcl_Interp *interp)); void Tcl_CallWhenDeleted(Tcl_Interp* interp, Tcl_InterpDeleteProc* proc, ClientData clientData); I intend on converted this to D thus: alias void function(ClientData clientData, Tcl_Interp* interp) Tcl_InterpDeleteProc; void Tcl_CallWhenDeleted(Tcl_Interp* interp, Tcl_InterpDeleteProc* proc, ClientData clientData); Is it correct keeping the * with the Tcl_InterpDeleteProc parameter or do i remove it? Is the alias above a function pointer? To call this function can i use a function literal for the Tcl_InterpDeleteProc parameter? or do i need to pass an address of the function?
Re: How to handle nested structs when converting C headers?
On Wednesday, 11 December 2013 at 23:36:11 UTC, bearophile wrote:
In D you can't define a struct/union and use it to define an
instance on the fly.
Well, you can if it is anonymous.
struct Foo {
union {
struct { ubyte a; ubyte b; }
ubyte[2] arr;
}
}
That works in D, and it makes foo.a == arr[0] and foo.b == arr[1];
Re: How to handle nested structs when converting C headers?
Adam D. Ruppe:
Well, you can if it is anonymous.
struct Foo {
union {
struct { ubyte a; ubyte b; }
ubyte[2] arr;
}
}
That works in D, and it makes foo.a == arr[0] and foo.b ==
arr[1];
Right :-) I like D structs.
Bye,
bearophile
Re: How to handle nested structs when converting C headers?
On Wednesday, 11 December 2013 at 23:38:13 UTC, Adam D. Ruppe
wrote:
On Wednesday, 11 December 2013 at 23:35:04 UTC, Gary Willoughby
wrote:
static union internalRep
try
static union InternalRep { /* note the capital letter */
/* snip */
}
InternalRep internalRep;; // still need a decl
Right. But why use the static keyword here?
Re: How to handle nested structs when converting C headers?
On Thu, Dec 12, 2013 at 12:54:58AM +0100, Gary Willoughby wrote:
On Wednesday, 11 December 2013 at 23:38:13 UTC, Adam D. Ruppe wrote:
On Wednesday, 11 December 2013 at 23:35:04 UTC, Gary Willoughby
wrote:
static union internalRep
try
static union InternalRep { /* note the capital letter */
/* snip */
}
InternalRep internalRep;; // still need a decl
Right. But why use the static keyword here?
Because nested structs by default carry a pointer to the containing
struct (or scope), which means it adds extra baggage and you can't
create the nested without also having an instance of the containing
struct.
T
--
It is of the new things that men tire --- of fashions and proposals and
improvements and change. It is the old things that startle and
intoxicate. It is the old things that are young. -- G.K. Chesterton
Re: Question about function aliases
On Wednesday, 11 December 2013 at 23:42:44 UTC, Gary Willoughby
wrote:
For example i have some C code like this:
typedef void (Tcl_InterpDeleteProc) _ANSI_ARGS_((ClientData
clientData, Tcl_Interp *interp));
void Tcl_CallWhenDeleted(Tcl_Interp* interp,
Tcl_InterpDeleteProc* proc, ClientData clientData);
I intend on converted this to D thus:
alias void function(ClientData clientData, Tcl_Interp* interp)
Tcl_InterpDeleteProc;
void Tcl_CallWhenDeleted(Tcl_Interp* interp,
Tcl_InterpDeleteProc* proc, ClientData clientData);
Is it correct keeping the * with the Tcl_InterpDeleteProc
parameter or do i remove it? Is the alias above a function
pointer?
To call this function can i use a function literal for the
Tcl_InterpDeleteProc parameter? or do i need to pass an address
of the function?
It's a function pointer.
Test:
import std.stdio;
alias extern(C) void function(void*) Callback;
void Call(Callback c)
{
c(c);
}
extern(C) void callback(void* v)
{
writefln(v: %04X, v);
}
void main()
{
Callback c = callback;
Call(c);
writefln(c: %04X, c);
}
Re: Type inference and overloaded functions
On Wednesday, 11 December 2013 at 23:20:30 UTC, bearophile wrote: Namespace: I'm pretty nervous, but here is the first: https://github.com/D-Programming-Language/dmd/pull/2952 Good. Keep in mind that at best it will take a month or more for your patch to be accepted. Also patches that implement basic language features like this pass a stringent process of review, that can be laborious and a bit painful. And even after after all that work there's a certain probability of rejection. So you have to build stamina and accumulate patience :-) (Other kind of patches, like D front-end bug fixes or Phobos improvements are faster and often much less painful). Bye, bearophile Your gig: https://github.com/D-Programming-Language/dmd/pull/2952#discussion_r8288045
Re: Type inference and overloaded functions
Ali Çehreli: int[] arr2 = [7, 8, 9]s; assert(is(typeof(arr2) == int[3])); That looks very confusing. The left-hand side looks like a slice, which I can append elements to but its type is a static array? No, the type of the literal is of a fixed-side array, but it gets assigned to a dynamic array, so it's a slice. I am not sure but I Think arr2 data is allocated on the stack. It looks a little confusing, but I think it contains a rule we can learn. Bye, bearophile
Re: Type inference and overloaded functions
Namespace:
Your gig:
https://github.com/D-Programming-Language/dmd/pull/2952#discussion_r8288045
My enhancement request was for the array[$] syntax. The idea of
[]s was invented by someone else (Timothee Cour?).
I like the practical comments by Hara. If Kenji thinks the []s is
not useful for efficiency (because the efficiency can be obtained
with just improvements of the compiler), then the []s syntax
becomes less necessary.
On the other hand this is an interesting use case that compiler
improvements alone could not be enough to allow:
void fun(int[3]) {}
void main() {
int[3] x = [1, 2, 3];
fun(x); // OK
fun([1, 2, 3]); // error
fun([1, 2, 3]s); // OK
}
Are vector ops supported?
int[6] a;
a = [1,2,3]s[] + [4,5,6]s[];
DIP34 is still a draft, and it shows, some corner cases are
missing in that document and need to be found, fleshed out and
added to the DIP34.
Bye,
bearophile
Re: Type inference and overloaded functions
On Wed, Dec 11, 2013 at 5:17 PM, bearophile bearophileh...@lycos.comwrote:
Namespace:
Your gig: https://github.com/D-Programming-Language/dmd/pull/
2952#discussion_r8288045
My enhancement request was for the array[$] syntax. The idea of []s was
invented by someone else (Timothee Cour?).
I like the practical comments by Hara. If Kenji thinks the []s is not
useful for efficiency (because the efficiency can be obtained with just
improvements of the compiler), then the []s syntax becomes less necessary.
On the other hand this is an interesting use case that compiler
improvements alone could not be enough to allow:
void fun(int[3]) {}
void main() {
int[3] x = [1, 2, 3];
fun(x); // OK
fun([1, 2, 3]); // error
fun([1, 2, 3]s); // OK
}
yes, that was the prime motivation for DIP34, being able to pass
un-ambiguously a static array to a function without having to declare an
intermediate variable first.
when fun() has overloads for both static and non-static arrays (or is just
declared as fun(T)(T a) ), the compiler cannot guess whether fun([1,2,3])
asks for static or dynamic array, and probably has to assume dynamic array.
And int[$] would require declaring a variable before passing it, eg:
int[$]x=[1,2,3].
With [1,2,3]s, there is no ambiguity.
Are vector ops supported?
int[6] a;
a = [1,2,3]s[] + [4,5,6]s[];
DIP34 is still a draft, and it shows, some corner cases are missing in
that document and need to be found, fleshed out and added to the DIP34.
Bye,
bearophile
Templating with Function Pointers?
I'd like to know if it's possible to create a templated function that takes a function pointer as an argument, and uses static ifs to generate different behaviors based on the type signature of the function pointer. More specifically, I want to create code generation functions for my JIT compiler, and template them based on a pointer to a function that implements the semantics of the operation being jitted. Not all of these operations take the same arguments, so I'd like to be able to template and generate different machine code. Is it possible to template based on a function pointer argument? If so, is it possible to use static ifs to know the return type or the argument types of the function pointer's signature, as well as how many arguments it takes?
Re: Type inference and overloaded functions
Timothee Cour:
void fun(int[3]) {}
void main() {
int[3] x = [1, 2, 3];
fun(x); // OK
fun([1, 2, 3]); // error
fun([1, 2, 3]s); // OK
}
Sorry, there's no error there.
yes, that was the prime motivation for DIP34,
It seems Hara has received your message:
https://d.puremagic.com/issues/show_bug.cgi?id=8903#c7
Bye,
bearophile
Re: Templating with Function Pointers?
On 12/11/2013 06:43 PM, Maxime Chevalier-Boisvert wrote:
Is it possible to template based on a function pointer argument? If so,
is it possible to use static ifs to know the return type or the argument
types of the function pointer's signature, as well as how many arguments
it takes?
That one is pretty straightforward:
import std.string;
void temp(Func)(Func func)
{
static if (is (Func == int function(double))) {
pragma(msg, Found an int(double));
} else static if (is (Func == ReturnT function(string, size_t),
ReturnT)) {
pragma(msg, format(This one returns %s, ReturnT.stringof));
}
}
int foo(double d)
{
return 42;
}
struct S
{}
S bar(string s, size_t st)
{
return S.init;
}
void main()
{
temp(foo);
temp(bar);
}
It is also possible to use alias template parameters or variadic
template parameters. You may want to look at std.concurrency's receive()
function implementation for more ideas.
Ali
Re: Win Headers
On Wednesday, 11 December 2013 at 09:04:32 UTC, frustrated2 wrote: Are there complete windows headers and if yes where can i find them and will they work for 64bit? there is mostly complete headers[1], however it is not and never be ready for x64. also there is Andrej Mitrovic's fork[2] of these, which you can make work with x64 with few(at moment of 2.063 due to bugs) to none manual fixes. [1] http://www.dsource.org/projects/bindings/wiki/WindowsApi [2] https://github.com/AndrejMitrovic/DWinProgramming/tree/master/WindowsAPI
Re: Templating with Function Pointers?
Thanks, I think the std.concurrency code demonstrates exactly
what I need :)
On Thursday, 12 December 2013 at 05:07:11 UTC, Ali Çehreli wrote:
On 12/11/2013 06:43 PM, Maxime Chevalier-Boisvert wrote:
Is it possible to template based on a function pointer
argument? If so,
is it possible to use static ifs to know the return type or
the argument
types of the function pointer's signature, as well as how
many arguments
it takes?
That one is pretty straightforward:
import std.string;
void temp(Func)(Func func)
{
static if (is (Func == int function(double))) {
pragma(msg, Found an int(double));
} else static if (is (Func == ReturnT function(string,
size_t), ReturnT)) {
pragma(msg, format(This one returns %s,
ReturnT.stringof));
}
}
int foo(double d)
{
return 42;
}
struct S
{}
S bar(string s, size_t st)
{
return S.init;
}
void main()
{
temp(foo);
temp(bar);
}
It is also possible to use alias template parameters or
variadic template parameters. You may want to look at
std.concurrency's receive() function implementation for more
ideas.
Ali
Re: Win Headers
thanks for your reply. its a shame that the language does not supply ready to use headers. i can live with missing libraries, but not with incomplete or non working bare minimal prerequisites to use it with an os. that is a sad and sorry state! On Thursday, 12 December 2013 at 05:30:29 UTC, evilrat wrote: On Wednesday, 11 December 2013 at 09:04:32 UTC, frustrated2 wrote: Are there complete windows headers and if yes where can i find them and will they work for 64bit? there is mostly complete headers[1], however it is not and never be ready for x64. also there is Andrej Mitrovic's fork[2] of these, which you can make work with x64 with few(at moment of 2.063 due to bugs) to none manual fixes. [1] http://www.dsource.org/projects/bindings/wiki/WindowsApi [2] https://github.com/AndrejMitrovic/DWinProgramming/tree/master/WindowsAPI
