DList!int.remove(range.takeOne) - workarounds?
DList seems to have an issue with remove:
void main()
{
import std.container, std.range, std.algorithm;
auto list = DList!int([1, 2, 4, 6]);
auto res = find(list[], 2);
list.remove(res); //ok
/*
list.remove(res.takeOne);
Error: function std.container.dlist.DList!int.DList.remove (Range
r) is not callable using argument types (Result)
list.remove(res.take(1));
Error: function std.container.dlist.DList!int.DList.remove (Range
r) is not callable using argument types (Take!(Range))
*/
}
Are there any known workarounds besides linearRemove?
Re: DList!int.remove(range.takeOne) - workarounds?
On Sunday, 12 October 2014 at 09:45:22 UTC, Algo wrote:
DList seems to have an issue with remove:
void main()
{
import std.container, std.range, std.algorithm;
auto list = DList!int([1, 2, 4, 6]);
auto res = find(list[], 2);
list.remove(res); //ok
/*
list.remove(res.takeOne);
Error: function std.container.dlist.DList!int.DList.remove
(Range r) is not callable using argument types (Result)
list.remove(res.take(1));
Error: function std.container.dlist.DList!int.DList.remove
(Range r) is not callable using argument types (Take!(Range))
*/
}
Are there any known workarounds besides linearRemove?
There is (unfortunatly) no support for takeOne in DList.
However, linearRemove is not a workaround or worst than remove.
It is just that it accepts a wider range of input, when O(1)
cannot be guaranteed. If you are operating with a range of length
1, then linearRemove is still O(1).
Re: DList!int.remove(range.takeOne) - workarounds?
On Sunday, 12 October 2014 at 10:35:19 UTC, monarch_dodra wrote:
On Sunday, 12 October 2014 at 09:45:22 UTC, Algo wrote:
DList seems to have an issue with remove:
void main()
{
import std.container, std.range, std.algorithm;
auto list = DList!int([1, 2, 4, 6]);
auto res = find(list[], 2);
list.remove(res); //ok
/*
list.remove(res.takeOne);
Error: function std.container.dlist.DList!int.DList.remove
(Range r) is not callable using argument types (Result)
list.remove(res.take(1));
Error: function std.container.dlist.DList!int.DList.remove
(Range r) is not callable using argument types (Take!(Range))
*/
}
Are there any known workarounds besides linearRemove?
There is (unfortunatly) no support for takeOne in DList.
However, linearRemove is not a workaround or worst than
remove. It is just that it accepts a wider range of input, when
O(1) cannot be guaranteed. If you are operating with a range of
length 1, then linearRemove is still O(1).
Thanks, linearRemove is fine, sorry for the misunderstanding
return types of std.functional functions
i found two snippets from the functional docs that do not work (anymore?) http://dlang.org/phobos/std_functional.html assert(compose!(map!(to!(int)), split)(1 2 3) == [1, 2, 3]); and int[] a = pipe!(readText, split, map!(to!(int)))(file.txt); throwing a std.array.array into the mix works fine. did this use to work? is there any other way of doing it?
Re: return types of std.functional functions
On 10/12/2014 08:04 AM, yawniek wrote: i found two snippets from the functional docs that do not work (anymore?) http://dlang.org/phobos/std_functional.html assert(compose!(map!(to!(int)), split)(1 2 3) == [1, 2, 3]); and int[] a = pipe!(readText, split, map!(to!(int)))(file.txt); throwing a std.array.array into the mix works fine. did this use to work? is there any other way of doing it? The proper way is to call std.algorithm.equal, which compares ranges element-by-element: assert(compose!(map!(to!(int)), split)(1 2 3).equal([1, 2, 3])); Ali
Re: return types of std.functional functions
yawniek: i found two snippets from the functional docs that do not work (anymore?) http://dlang.org/phobos/std_functional.html assert(compose!(map!(to!(int)), split)(1 2 3) == [1, 2, 3]); and int[] a = pipe!(readText, split, map!(to!(int)))(file.txt); throwing a std.array.array into the mix works fine. did this use to work? I think those were little used, and today with UFCS they are even less useful. is there any other way of doing it? Untested: 1 2 3.split.to!(int[]) == [1, 2, 3] int[] a = file.txt.readText.split.to!(int[]); Once to!() accepts a lazy iterable you can save some GC activity with: 1 2 3.splitter.to!(int[]) == [1, 2, 3] int[] a = file.txt.readText.splitter.to!(int[]); Currently you have to write this to do the same: 1 2 3.splitter.map!(to!int).array == [1, 2, 3] int[] a = file.txt.readText.splitter.map!(to!(int)).array; But you can also omit the latest .array: 1 2 3.splitter.map!(to!int).equal([1, 2, 3]) Bye, bearophile
Re: [yajl-d] hello world with json arrays
On Sunday, 12 October 2014 at 04:17:42 UTC, Jack wrote:
Disclaimer: Don't eat me.
I was just wondering to those who are experienced in using
yajl-d to show me the proper implementation of using it with
arrays.
So far this is what I understand from parsing Json Objects:
class random{
private string foo;
private string bar;
}
void main(string [] args){
random rand = decode!random(to!string(read(json_file.json)));
//do stuff
Now I'm just wondering how can I implement it with Json arrays.
Just some information or a place to start with is all I ask.
Thank you.
Nvm for this. I found a code snippet from sir Ali that suited the
job.
http://forum.dlang.org/thread/jkndf7$ma3$1...@digitalmars.com
Re: building shared library from D code to import into cython
Thanks for this. I am aware of pyd and will take a look at source/build process. Any thoughts on speed in 2014 of pyd vs using cython to talk to D directly via C/C++ interface? I saw this old coment here: prabhuramachandran.blogspot.co.uk/2008/09/python-vs-cython-vs-d-pyd-vs-c-swig predict that the D version's relative slowness might have something to do with Pyd's somewhat awful handling of arrays (at least in part). More low-level and verbose, but possibly faster code could be written to compensate for this if this is indeed the problem. However, this is not a very attractive solution. (Optimally, Pyd should be capable of directly pointing D arrays at numpy arrays, but this is not actually implemented.) On Friday, 10 October 2014 at 02:19:17 UTC, Ellery Newcomer wrote: On Wednesday, 8 October 2014 at 00:25:57 UTC, Laeeth Isharc wrote: Hi. Thanks for the quick response. The -defaultlib was left around from trying all kinds of combinations of dmd and gcc. I am not used to gcc, and it will take me some time to become properly acquainted with all the options. I managed to get it to compile with default dmd rpm: https://github.com/ariovistus/cythonic_d fedora 20, x86_64 Are you aware of pyd? (https://bitbucket.org/ariovistus/pyd) It knows how to build shared libraries, so I recommend you play with it, if only to watch how it does that. Biggest gotcha is starting up druntime.
Re: building shared library from D code to import into cython
On Sunday, 12 October 2014 at 16:07:19 UTC, Laeeth Isharc wrote: Any thoughts on speed in 2014 of pyd vs using cython to talk to D directly via C/C++ interface? I saw this old coment here: pyd is basically just a convenience layer on top of the C interface. The part that would most likely screw with performance would be conversion from D objects to python objects and vice versa since that normally does a value copy. At the time of that comment, pyd's strategy for arrays was just iterate and convert each element. Now pyd can take advantage of the buffer protocol if it is exposed (2.7+), so converting e.g. numpy arrays should be just a memcopy. If you want by ref semantics instead of by value, use PydObject instead of a D type in your function signature. You can also turn off all conveniences and just use the C api with raw_only (https://bitbucket.org/ariovistus/pyd/wiki/CeleriD)
Method signature differences in core modules on dmd and gdc?
I've been recently trying GDC out to compile some D code and i'm running into the problem of differing function signatures in core modules. For example: stack.d:79: error: function core.memory.GC.calloc (ulong sz, uint ba = 0u) is not callable using argument types (ulong, BlkAttr, TypeInfo_Array) stack.d:110: error: function core.memory.GC.realloc (void* p, ulong sz, uint ba = 0u) is not callable using argument types (string*, ulong, BlkAttr, TypeInfo_Array) snip These compile fine using DMD. Anybody know what the issue is here?
Re: Method signature differences in core modules on dmd and gdc?
On Sun, 12 Oct 2014 19:20:47 + Gary Willoughby via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: These compile fine using DMD. Anybody know what the issue is here? gdc is still 2.065, while official dmd is 2.066. signatures of this functions was changed inbetween. or maybe that was changed for upcoming 2.067, i don't remember. signature.asc Description: PGP signature
Re: Method signature differences in core modules on dmd and gdc?
On Sunday, 12 October 2014 at 19:20:49 UTC, Gary Willoughby wrote: I've been recently trying GDC out to compile some D code and i'm running into the problem of differing function signatures in core modules. For example: stack.d:79: error: function core.memory.GC.calloc (ulong sz, uint ba = 0u) is not callable using argument types (ulong, BlkAttr, TypeInfo_Array) stack.d:110: error: function core.memory.GC.realloc (void* p, ulong sz, uint ba = 0u) is not callable using argument types (string*, ulong, BlkAttr, TypeInfo_Array) snip These compile fine using DMD. Anybody know what the issue is here? GDC is still on version 2.065.
how to call class' template constructor
Hello.
please, how to call template constructor of a class? it's completely
escaped my mind. i.e. i have this class:
class A {
this(alias ent) (string name) {
...
}
}
and i want to do:
void foo () { ... }
auto a = new A!foo(xFn);
yet compiler tells me that
template instance A!foo A is not a template declaration, it is a class
yes, i know that i can rewrite constructor to something like this:
this(T) (string name, T fn) if (isCallable!T) {
...
}
and then use autodeduction, but i want the first form! ;-)
signature.asc
Description: PGP signature
Really in need of help with std.container.array.d
I'm trying to figure out how to add complete support for constness in std.container.array.Array at https://github.com/D-Programming-Language/phobos/commit/703305f0bfb1cc22eff3e44e351cc3db3e03f94f#commitcomment-8114056 My current solution (which currently fails) at https://github.com/nordlow/phobos/commit/5c57cb18c2b9d340a19d19207deca5af0339cf7e#diff-0 tries to solve the problem by making wrapper struct Range a template that captures the constness of parenting Array. My current implementation of array.d at https://github.com/nordlow/phobos/blob/inout-array-range/std/container/array.d#L221 however fails its unittests as array.d(223,19): Error: variable std.container.array.Array!int.Array.Range!(inout(Array!int)).Range._outer only parameters or stack based variables can be inout array.d(430,5): Error: template instance std.container.array.Array!int.Array.Range!(inout(Array!int)) error instantiating array.d(833,5):instantiated from here: Array!int array.d(862,5): Error: static assert (!true) is false and I have no clue how to proceed with this. Please help, me and at least one other D developer is hindered by this.
Re: how to call class' template constructor
On Sunday, 12 October 2014 at 19:46:41 UTC, ketmar via
Digitalmars-d-learn wrote:
Hello.
please, how to call template constructor of a class? it's
completely
escaped my mind. i.e. i have this class:
class A {
this(alias ent) (string name) {
...
}
}
and i want to do:
void foo () { ... }
auto a = new A!foo(xFn);
Template the whole class? class A(alias ent)?
Re: Really in need of help with std.container.array.d
On Sunday, 12 October 2014 at 20:17:38 UTC, Nordlöw wrote: https://github.com/nordlow/phobos/commit/5c57cb18c2b9d340a19d19207deca5af0339cf7e#diff-0 Made some corrections https://github.com/nordlow/phobos/compare/inout-array-range but gives a similar error array.d(223,19): Error: variable std.container.array.Array!int.Array.Range!(inout(Array!int)).Range._outer only parameters or stack based variables can be inout array.d(430,5): Error: template instance std.container.array.Array!int.Array.Range!(inout(Array!int)) error instantiating array.d(833,5):instantiated from here: Array!int array.d(816,5): Error: template instance std.container.array.Array!int.Array.Range!(Array!int) error instantiating array.d(833,5):instantiated from here: Array!int array.d(862,5): Error: static assert (!true) is false
Re: how to call class' template constructor
On Sunday, 12 October 2014 at 19:46:41 UTC, ketmar via
Digitalmars-d-learn wrote:
Hello.
please, how to call template constructor of a class? it's
completely
escaped my mind. i.e. i have this class:
class A {
this(alias ent) (string name) {
...
}
}
and i want to do:
void foo () { ... }
auto a = new A!foo(xFn);
yet compiler tells me that
template instance A!foo A is not a template declaration, it is
a class
yes, i know that i can rewrite constructor to something like
this:
this(T) (string name, T fn) if (isCallable!T) {
...
}
and then use autodeduction, but i want the first form! ;-)
How about a static factory method? Or do you know there is a
syntax for invoking a templatized constructor and just can't
remember it?
Re: how to call class' template constructor
On Sunday, 12 October 2014 at 19:46:41 UTC, ketmar via
Digitalmars-d-learn wrote:
Hello.
please, how to call template constructor of a class? it's
completely
escaped my mind. i.e. i have this class:
class A {
this(alias ent) (string name) {
...
}
}
and i want to do:
void foo () { ... }
auto a = new A!foo(xFn);
yet compiler tells me that
template instance A!foo A is not a template declaration, it is
a class
I think there's no nice way to explicitly pass template arguments
to constructors. Here's a hack:
auto a = cast(A) (new void[__traits(classInstanceSize,
A)]).ptr;
a.__ctor!foo(xFn);
I didn't think this through or test it thoroughly. So it most
probably has issues. You could try to identify and fix them, and
then hide the ugly away in a function.
But the two leading underscores tell it: __ctor is an
implementation detail. It may disappear/change without notice.
Some other solution/workaround would probably be the better
choice. Like a static factory method that's already been
mentioned.
Re: how to call class' template constructor
On Sun, 12 Oct 2014 20:29:39 + JR via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Template the whole class? class A(alias ent)? no, that will produce different classes for different types, and i need just one class, but initialized with different entities. with templated class i need to make A ancestor of some BaseA to make checks with `cast(...)`. On Sun, 12 Oct 2014 20:35:52 + Cliff via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: How about a static factory method? i still need to call templated constructor with it. and i want to init some immutable fields in it, and that fields depends of entity. sure, i can write alot of non-templated constructors and call 'em from factory method, or make other changes, but it leads to code bloat. i want to avoid id. Or do you know there is a syntax for invoking a templatized constructor and just can't remember it? no, i'm not even sure that such syntax exists. i always used templated constructors with autodeduction. On Sun, 12 Oct 2014 20:49:29 + anonymous via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I think there's no nice way to explicitly pass template arguments to constructors. Here's a hack: i know about hackish way, but it's SOOO UUUGLY... ;-) thank you anyway. But the two leading underscores tell it: __ctor is an implementation detail. It may disappear/change without notice. ah, that's ok, i'm relying on other implementation details too, one more will not make much difference. thank you people. seems that there is no official way to call such constructors. ok, i converted it to autodeducing one, one more argument doesn't really matter, it's hidden in another template anyway. i was just curious if i missed some nice syntax here, or we have no way to do this without resorting to hack or factory function. signature.asc Description: PGP signature
Re: Method signature differences in core modules on dmd and gdc?
On Sunday, 12 October 2014 at 19:34:30 UTC, Iain Buclaw wrote: On Sunday, 12 October 2014 at 19:20:49 UTC, Gary Willoughby wrote: I've been recently trying GDC out to compile some D code and i'm running into the problem of differing function signatures in core modules. For example: stack.d:79: error: function core.memory.GC.calloc (ulong sz, uint ba = 0u) is not callable using argument types (ulong, BlkAttr, TypeInfo_Array) stack.d:110: error: function core.memory.GC.realloc (void* p, ulong sz, uint ba = 0u) is not callable using argument types (string*, ulong, BlkAttr, TypeInfo_Array) snip These compile fine using DMD. Anybody know what the issue is here? GDC is still on version 2.065. Ah right, so these methods changed recently?
Re: Method signature differences in core modules on dmd and gdc?
On Sun, 12 Oct 2014 22:05:16 + Gary Willoughby via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Ah right, so these methods changed recently? yes. this is from gdc source: static void* calloc( size_t sz, uint ba = 0 ) pure nothrow and this is from current dmd HEAD: static void* calloc( size_t sz, uint ba = 0, const TypeInfo ti = null ) pure nothrow signature.asc Description: PGP signature
Re: how to call class' template constructor
On 10/12/14 3:46 PM, ketmar via Digitalmars-d-learn wrote:
Hello.
please, how to call template constructor of a class? it's completely
escaped my mind. i.e. i have this class:
class A {
this(alias ent) (string name) {
...
}
}
and i want to do:
void foo () { ... }
auto a = new A!foo(xFn);
yet compiler tells me that
template instance A!foo A is not a template declaration, it is a class
yes, i know that i can rewrite constructor to something like this:
this(T) (string name, T fn) if (isCallable!T) {
...
}
and then use autodeduction, but i want the first form! ;-)
Hm... I don't think it's very possible, unless you want to call ctor
directly and not conflate with new (i.e. define a factory function
instead). Unfortunately, some things can only be done within constructors.
At least someone else has found a similar issue before:
https://issues.dlang.org/show_bug.cgi?id=10689
I'm not sure what proper syntax would be, perhaps:
auto a = (new A)!foo(xFn);
A good pattern should be able to be discovered here, to help with the
existing state of affairs...
-Steve
