Re: The hackathon week roundup
On 5/2/2015 7:43 PM, Rikki Cattermole wrote: Shouldn't it be creative commons because it is more a creative work aka documentation? Everything else is boost licensed. Consistency.
Re: The hackathon week roundup
On 5/2/2015 7:43 PM, Rikki Cattermole wrote: Shouldn't it be creative commons because it is more a creative work aka documentation? Everything else is boost licensed. Consistency.
Re: DTiled: Tiled map loader
On Saturday, 2 May 2015 at 19:16:03 UTC, rcorre wrote: Any D game developers out there looking to create a tile-based game? DTiled aims to provide a quick and easy way to load maps created with Tiled Good! Thank you!
Re: DTiled: Tiled map loader
Nice that you named Dgame on your repo. ;) As soon as it supports XML and CSV I would definitely use it. Everyone who starts a game in D calls it Dgame!
Re: Building DMD on SmartOS
On Thursday, 30 April 2015 at 17:39:02 UTC, flamencofantasy wrote: Hello, I would like to use D on SmartOS. Since there is no binary installer I tried to build DMD from source by following the instructions on this page; http://wiki.dlang.org/Building_DMD Unfortunately I get this error; [~/d/dmd/src]# make -f posix.mak MODEL=64 no cpu specified, assuming X86 dmd idgen.d make: dmd: Command not found posix.mak:320: recipe for target 'idgen' failed make: *** [idgen] Error 127 I spent a couple hours and installed SmartOS in a VM, my first time ever messing with SmartOS though I've run and developed for Solaris before, to see what the status of building dmd is. While it was a pain getting SmartOS configured, I was finally able to build dmd 2.067 and druntime without a problem, using gcc 4.7 (the clang from pkgin tried to use some linker config that wouldn't work to link even basic test C++ files). Phobos now keeps failing to build on me, but only because I'm low on disk space and it keeps running out of swap. However, linking a small sample file against druntime alone fails, some issue with the deh_beg/deh_end sections: gcc sieve.o ./lib/libdruntime-solaris64.a -o sieve -m64 -lpthread -lm ld: fatal: symbol '_deh_beg' in file sieve.o: section [15].deh_beg: size 0: symbol (address 0, size 0x4) lies outside of containing section ld: fatal: symbol '_deh_end' in file sieve.o: section [17].deh_end: size 0: symbol (address 0, size 0x4) lies outside of containing section ld: fatal: file processing errors. No output written to sieve collect2: error: ld returned 1 exit status I'll finish building phobos and mess around a bit with fixing those sections. I'll let you know if I get it to work.
Re: std.random question
On Sunday, 3 May 2015 at 09:04:07 UTC, tired_eyes wrote:
On Sunday, 3 May 2015 at 08:48:52 UTC, Dennis Ritchie wrote:
On Sunday, 3 May 2015 at 08:42:57 UTC, tired_eyes wrote:
Feels pretty silly, but I can't compile this:
import std.random;
auto i = uniform(0, 10);
DMD spits this:
/usr/include/dmd/phobos/std/random.d(1188): Error: static
variable initialized cannot be read at compile time
/usr/include/dmd/phobos/std/random.d(1231):called
from here: rndGen()
/usr/include/dmd/phobos/std/random.d(1231):called
from here: uniform(a, b, rndGen())
Perhaps I'm missing something obvious?
dmd 2.067.1, openSUSE 13.2 x64
void main() {
import std.random;
auto i = uniform(0, 10);
}
Not so simple, unfortunately.
Actual code:
import std.random;
struct Mystruct {
auto id = uniform(0, 10);
}
void main() {
// wahtever
}
..and no luck.
I think it is a bug:
import std.stdio, std.random;
struct Mystruct {
//mixin(`auto id = uniform(0, 10);`);
// Error: static variable initialized cannot be read at compile
time
int val;
}
void main() {
Mystruct test;
test.val = uniform(0, 10); // OK
writeln(test.val);
mixin(`auto n = uniform(0, 10);`); // OK
}
Re: The most awesome forward to member solution?
On Sunday, 3 May 2015 at 05:49:52 UTC, Andrei Alexandrescu wrote: On 5/2/15 10:00 PM, Meta wrote: It seems like it'd be a lot cheaper and cleaner to just be able to alias the parent method. Yeh, that's the first solution that comes to mind. alias doesn't work here but of course we could change the language. Also, it could probably be made a bit simpler with opDispatch. I'd have to see the code, but my intuition is that things could get quite a bit more hairy. Andrei IMO, using __traits and opDispatch is a fair bit cleaner, and I prefer the syntax of a mixin template to regular mixin. http://dpaste.dzfl.pl/d60498246577
Re: The hackathon week roundup
On Sunday, 3 May 2015 at 04:13:35 UTC, Andrei Alexandrescu wrote: On 5/2/15 6:27 PM, Walter Bright wrote: On 5/2/2015 5:12 PM, Andrei Alexandrescu wrote: On 5/2/15 4:50 PM, Ilya Yaroshenko wrote: * Tutorial: http://d.readthedocs.org (btw should we link that from the homepage?) May I transfer the repositories (both GitHub and RTD) to the D-Programming-Language community? That'd be a fine idea. Thoughts from Walter, Martin et al? -- Andrei I think it's a great idea. It'd have to be Boost licensed, though. Ilya, your turn. Proceed and be bold. -- Andrei I have requested repository transfer to Andrei because only members of a organisation can transfer. Andrey or/and someone from D core team, please send me your user names at readthedocs.org.
Re: The hackathon week roundup
On Sunday, 3 May 2015 at 04:13:35 UTC, Andrei Alexandrescu wrote: On 5/2/15 6:27 PM, Walter Bright wrote: On 5/2/2015 5:12 PM, Andrei Alexandrescu wrote: On 5/2/15 4:50 PM, Ilya Yaroshenko wrote: * Tutorial: http://d.readthedocs.org (btw should we link that from the homepage?) May I transfer the repositories (both GitHub and RTD) to the D-Programming-Language community? That'd be a fine idea. Thoughts from Walter, Martin et al? -- Andrei I think it's a great idea. It'd have to be Boost licensed, though. Ilya, your turn. Proceed and be bold. -- Andrei I have requested repository transfer to Andrei because only members of a organisation can transfer. Andrey or/and someone from D core team, please send me your user names at readthedocs.org.
Re: The most awesome forward to member solution?
Wow, ParameterTypeTuple even works with ref arguments with no problem. That's impressive.
Re: Parameter storage class 'in' transitive like 'const'?
On Sunday, 3 May 2015 at 05:20:34 UTC, Ali Çehreli wrote:
We know that 'in' is equivalent to const scope:
http://dlang.org/function.html#parameters
So, the constness of 'in' is transitive as well, right?
Ali
Of course, there's no concept of non-transitive const in D:
struct S
{
char[] str;
}
void foo(in S s)
{
pragma(msg, typeof(s.str)); // const(char[])
}
Re: The most awesome forward to member solution?
On Sunday, 3 May 2015 at 00:25:13 UTC, Dicebot wrote: Sounds similar to http://dlang.org/phobos/std_typecons.html#.Proxy Great documentation by the way. I understood what it does with one read: Make proxy for a.
Re: compile time garbage collection
On Sunday, 3 May 2015 at 04:46:52 UTC, ketmar wrote: i don't thing that such pass in general worth the efforts. D programmers tend to use structures for local and short-lived objects. if i did `new`, chances are that i really want it on heap, and it will not be optimisable This is where one have to decide whether to make a low/system level language with programmer control or a high level language with compiler control. If you have GC by default, then it makes a lot of sense to not even have a stack conceptually and do explicit allocations and stack allocation as an optimization. But yeah, a system level language should allow threads to be terminated which would prevent destructors from being called, and since GC call destructors on another thread it will change program behaviour to turn GC allocations into stack allocations in general... so it can catch very rare cases for the cost of expensive interprocedural analysis. this makes some sense for C++, though. Well, if D is to be a higher level language than C++, then it makes more sense for D. Especially since a threaded view through non-shared objects could allow better analysis, but that would require a 100% ban on transferring non-shared pointers to shared pointers. D really needs to get a well defined memory model.
Re: Parameter storage class 'in' transitive like 'const'?
On Saturday, May 02, 2015 22:20:33 Ali Çehreli via Digitalmars-d-learn wrote: We know that 'in' is equivalent to const scope: http://dlang.org/function.html#parameters So, the constness of 'in' is transitive as well, right? Of course. in is identical to const scope. It doesn't introduce anything new. It's basically just an alias. And I really wish that folks would stop using it, since it implies scope, and scope hasn't been properly implemented or even designed out yet... - Jonathan M Davis
Re: compile time garbage collection
On Sunday, 3 May 2015 at 08:02:37 UTC, Ola Fosheim Grøstad wrote: On Sunday, 3 May 2015 at 04:46:52 UTC, ketmar wrote: i don't thing that such pass in general worth the efforts. D programmers tend to use structures for local and short-lived objects. if i did `new`, chances are that i really want it on heap, and it will not be optimisable This is where one have to decide whether to make a low/system level language with programmer control or a high level language with compiler control. If you have GC by default, then it makes a lot of sense to not even have a stack conceptually and do explicit allocations and stack allocation as an optimization. But yeah, a system level language should allow threads to be terminated which would prevent destructors from being called, and since GC call destructors on another thread it will change program behaviour to turn GC allocations into stack allocations in general... there's no guarantee GC allocated memory will _ever_ have their destructor ran, it's part of the spec. The garbage collector is not guaranteed to run the destructor for all unreferenced objects.
Re: The most awesome forward to member solution?
On Sunday, 3 May 2015 at 07:55:30 UTC, tcak wrote: On Sunday, 3 May 2015 at 00:25:13 UTC, Dicebot wrote: Sounds similar to http://dlang.org/phobos/std_typecons.html#.Proxy Great documentation by the way. I understood what it does with one read: Make proxy for a. http://dlang.org/phobos-prerelease/std_typecons.html#.Proxy
Re: compile time garbage collection
On Sunday, 3 May 2015 at 08:22:31 UTC, weaselcat wrote: there's no guarantee GC allocated memory will _ever_ have their destructor ran, it's part of the spec. That would be very unfortunate, they have to either be called eventually or never called. I find no such description in the spec: http://dlang.org/garbage.html «5. Freeing all GC allocated memory that has no active pointers to it and do not need destructors to run. 6. Queueing all unreachable memory that needs destructors to run. 7. Resuming all other threads. 8. Running destructors for all queued memory.»
Re: Building DMD on SmartOS
On Sunday, 3 May 2015 at 07:04:17 UTC, Joakim wrote: I'll finish building phobos and mess around a bit with fixing those sections. I'll let you know if I get it to work. Alright, increasing the RAM in my VM got phobos to build. However, linking sample files and the tests still fail because of that linker issue. Jason, it appears that you are familiar with the peculiar ELF linking issues: https://www.illumos.org/issues/308 I'm uninterested in digging into these ELF binary issues, so it's all yours, if you want it. I can verify any fix you come up with in this zone that's eating up a ton of disk space on my SSD.
std.random question
Feels pretty silly, but I can't compile this: import std.random; auto i = uniform(0, 10); DMD spits this: /usr/include/dmd/phobos/std/random.d(1188): Error: static variable initialized cannot be read at compile time /usr/include/dmd/phobos/std/random.d(1231):called from here: rndGen() /usr/include/dmd/phobos/std/random.d(1231):called from here: uniform(a, b, rndGen()) Perhaps I'm missing something obvious? dmd 2.067.1, openSUSE 13.2 x64
Re: compile time garbage collection
On Sunday, 3 May 2015 at 08:34:09 UTC, Ola Fosheim Grøstad wrote: On Sunday, 3 May 2015 at 08:22:31 UTC, weaselcat wrote: there's no guarantee GC allocated memory will _ever_ have their destructor ran, it's part of the spec. That would be very unfortunate, they have to either be called eventually or never called. I find no such description in the spec: http://dlang.org/garbage.html «5. Freeing all GC allocated memory that has no active pointers to it and do not need destructors to run. 6. Queueing all unreachable memory that needs destructors to run. 7. Resuming all other threads. 8. Running destructors for all queued memory.» http://dlang.org/class.html#destructors
Re: std.random question
On Sunday, 3 May 2015 at 08:42:57 UTC, tired_eyes wrote:
Feels pretty silly, but I can't compile this:
import std.random;
auto i = uniform(0, 10);
DMD spits this:
/usr/include/dmd/phobos/std/random.d(1188): Error: static
variable initialized cannot be read at compile time
/usr/include/dmd/phobos/std/random.d(1231):called from
here: rndGen()
/usr/include/dmd/phobos/std/random.d(1231):called from
here: uniform(a, b, rndGen())
Perhaps I'm missing something obvious?
dmd 2.067.1, openSUSE 13.2 x64
void main() {
import std.random;
auto i = uniform(0, 10);
}
Re: compile time garbage collection
On Sunday, 3 May 2015 at 08:41:04 UTC, weaselcat wrote: http://dlang.org/class.html#destructors Oh well, that should be described under GC too then, but it can improve collection speed so I guess it is ok if one requires classes to be marked @nogc if they have destructors. The inbetween position is just dangerous.
Re: std.random question
On Sunday, 3 May 2015 at 08:48:52 UTC, Dennis Ritchie wrote:
On Sunday, 3 May 2015 at 08:42:57 UTC, tired_eyes wrote:
Feels pretty silly, but I can't compile this:
import std.random;
auto i = uniform(0, 10);
DMD spits this:
/usr/include/dmd/phobos/std/random.d(1188): Error: static
variable initialized cannot be read at compile time
/usr/include/dmd/phobos/std/random.d(1231):called from
here: rndGen()
/usr/include/dmd/phobos/std/random.d(1231):called from
here: uniform(a, b, rndGen())
Perhaps I'm missing something obvious?
dmd 2.067.1, openSUSE 13.2 x64
void main() {
import std.random;
auto i = uniform(0, 10);
}
Not so simple, unfortunately.
Actual code:
import std.random;
struct Mystruct {
auto id = uniform(0, 10);
}
void main() {
// wahtever
}
..and no luck.
Re: UDA and ReturnType!(__traits...) doesn't work
On Sunday, 3 May 2015 at 17:22:00 UTC, filcuc wrote:
Hi all,
i'm working in the generation of the code but i'm failing in
extracting a function return type when invoking the
ReturnType!(T) type trait and mixing it with
__traits(getMember) function.
Can anyone help me? or explaining what is happenning?
i've created a gist here:
https://gist.github.com/filcuc/14c3a6cac89beb69cccd
The error message is the following:
main.d-mixin-58(58): Error: template instance
main.Person.ReturnType!(name) does not match template
declaration ReturnType(func...) if (func.length == 1
isCallable!func)
main.d-mixin-58(58): Error: template instance
std.traits.ReturnType!(Monitor) does not match template
declaration ReturnType(func...) if (func.length == 1
isCallable!func)
main.d(73): Error: template instance main.IterateUDA!(Person)
error instantiating
Try adding the following around your 'string returnType = ...'
code:
static if(isSomeFunction!(__traits(get member, T, member))
{
...
}
The problem is that you're looping over all the fields in T,
including the data members which obviously don't have a return
type. I guess ReturnType should probably use a static assert to
give a better error message.
Re: Classes. C++ to D
On Sunday, 3 May 2015 at 17:35:42 UTC, Dennis Ritchie wrote:
Hi,
How can I rewrite this code to the D?
-
#include string
#include iostream
class A {
public:
std::string a() {
return std::string(foo);
}
};
class B {
public:
std::string b(){
return std::string(bar);
}
};
class C : public A, public B {};
int main () {
C c;
std::cout c.a() c.b() std::endl;
return 0;
}
This is not really doable right now in D. You can forward the
function calls to a and b easily enough, but you can't inherit
from more than one class. Once the multiple alias this patch gets
merged you will be able to do this in D.
Re: UDA and ReturnType!(__traits...) doesn't work
On Sun, 03 May 2015 17:21:58 +, filcuc wrote:
Hi all,
i'm working in the generation of the code but i'm failing in extracting
a function return type when invoking the ReturnType!(T) type trait and
mixing it with __traits(getMember) function.
Can anyone help me? or explaining what is happenning?
i've created a gist here:
https://gist.github.com/filcuc/14c3a6cac89beb69cccd
The error message is the following:
main.d-mixin-58(58): Error: template instance
main.Person.ReturnType!(name) does not match template declaration
ReturnType(func...) if (func.length == 1 isCallable!func)
main.d-mixin-58(58): Error: template instance
std.traits.ReturnType!(Monitor) does not match template declaration
ReturnType(func...) if (func.length == 1 isCallable!func)
main.d(73): Error: template instance main.IterateUDA!(Person) error
instantiating
the thing is that you mixed CTFE and runtime code in a weird way. ;-)
the following works:
void IterateUDA(T)() {
import std.typetuple : staticIndexOf;
foreach (member; __traits(allMembers, T)) {
// Check that the given member is a function
static if (is(typeof(__traits(getMember, T, member {
bool isFunction = __traits(isVirtualFunction, __traits(getMember,
T, member));
if (!isFunction) continue;
// Retrieve the UDA
enum attributes = __traits(getAttributes, __traits(getMember, T,
member));
// Extract the Function Return Type and Arguments if `Slot()` is
found
static if (staticIndexOf!(Slot(), attributes) = 0) {
enum returnType = ReturnType!(__traits(getMember, T,
member)).stringof;
import std.stdio;
writeln(returnType);
}
}
}
}
yet i think you need to read more about CTFE and metaprogramming, to
avoid mixing different code.
signature.asc
Description: PGP signature
Re: std.xml2 (collecting features)
- CTS to disable parsing location (line,column)
Re: std.xml2 (collecting features)
On Sunday, 3 May 2015 at 17:39:48 UTC, Robert burner Schadek wrote: std.xml has been considered not up to specs nearly 3 years now. Time to build a successor. I currently plan the following featues for it: - SAX and DOM parser - in-situ / slicing parsing when possible (forward range?) - compile time switch (CTS) for lazy attribute parsing - CTS for encoding (ubyte(ASCII), char(utf8), ... ) - CTS for input validating - performance Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 Please post you feature requests, and please keep the posts DRY and on topic. My request: just skip it. XML is a horrible waste of space for a standard, better D doesn't support it well, anything to discourage it's use. I'd rather see you spend your time on something worthwhile. If data formats are your thing, you could help get Ludwig's JSON stuff in, or better yet, enable some nice binary data format.
Re: std.xml2 (collecting features)
On 5/3/2015 10:39 AM, Robert burner Schadek wrote: Please post you feature requests, and please keep the posts DRY and on topic. Pipeline range interface, for example: source.xmlparse(configuration).whatever();
Re: The hackathon week roundup
On Sunday, 3 May 2015 at 04:13:35 UTC, Andrei Alexandrescu wrote: On 5/2/15 6:27 PM, Walter Bright wrote: On 5/2/2015 5:12 PM, Andrei Alexandrescu wrote: On 5/2/15 4:50 PM, Ilya Yaroshenko wrote: * Tutorial: http://d.readthedocs.org (btw should we link that from the homepage?) May I transfer the repositories (both GitHub and RTD) to the D-Programming-Language community? That'd be a fine idea. Thoughts from Walter, Martin et al? -- Andrei I think it's a great idea. It'd have to be Boost licensed, though. Ilya, your turn. Proceed and be bold. -- Andrei Project Home https://readthedocs.org/projects/d/ Repository https://github.com/andralex/thenextafterc Short URLs http://d.readthedocs.org http://d.rtfd.org
Re: The hackathon week roundup
On Sunday, 3 May 2015 at 04:13:35 UTC, Andrei Alexandrescu wrote: On 5/2/15 6:27 PM, Walter Bright wrote: On 5/2/2015 5:12 PM, Andrei Alexandrescu wrote: On 5/2/15 4:50 PM, Ilya Yaroshenko wrote: * Tutorial: http://d.readthedocs.org (btw should we link that from the homepage?) May I transfer the repositories (both GitHub and RTD) to the D-Programming-Language community? That'd be a fine idea. Thoughts from Walter, Martin et al? -- Andrei I think it's a great idea. It'd have to be Boost licensed, though. Ilya, your turn. Proceed and be bold. -- Andrei Project Home https://readthedocs.org/projects/d/ Repository https://github.com/andralex/thenextafterc Short URLs http://d.readthedocs.org http://d.rtfd.org
Re: Building DMD on SmartOS
It's not broken, dmd is emitting an arguably invalid elf section. On Sun, May 3, 2015 at 12:34 PM, Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 3 May 2015 at 16:02:54 UTC, Joakim wrote: On Sunday, 3 May 2015 at 15:06:24 UTC, flamencofantasy wrote: Thanks everyone for spending the time on this! I followed the steps and I got to the same point, that is I have built DMD, druntime and phobos successfully but linking fails as pointed out previously. My version of binutils is; binutils-2.24nb3;GNU binary utilities Same here. Kai, do we need to get 2.25 or is 2.24 good enough? Hmm, looking at the linker command invoked by gcc, it says it's calling collect2, but it also spits out a version string for the Solaris linker, so maybe it's really using that. I'm not interested in debugging the broken Solaris toolchain, so I'll leave it here.
Re: The most awesome forward to member solution?
On Sunday, 3 May 2015 at 23:54:49 UTC, Andrei Alexandrescu wrote:
On 5/3/15 4:20 PM, Meta wrote:
On Sunday, 3 May 2015 at 20:25:45 UTC, Andrei Alexandrescu
wrote:
OK, here's what I have now - two templates that are self
contained and
work well:
The first uses opDispatch to dispatch to a member. The second
is a
simple string function that generates the appropriate code. As
discussed the latter composes but the former doesn't.
I can't picture what you're talking about. Could you post an
example?
struct A
{
void fun(int);
}
struct B
{
A a;
mixin forwardToMember!(a, fun);
}
struct C
{
B b;
mixin forwardToMember!(b, fun);
}
Andrei
I still don't get it. Your example works with both
dispatchToMember and forwardToMember. What is the difference
between these two exactly?
auto opDispatch(string sym: foo)(ParemeterTypeTuple!(/*etc*/)
args)
{
return parent.foo(args);
}
//Automatically generated
auto foo(ParameterTypeTuple!(/*etc*/) args)
{
return parent.foo(args);
}
Re: The most awesome forward to member solution?
On 5/3/15 11:54 AM, Andrei Alexandrescu wrote:
On 5/3/15 12:18 AM, Meta wrote:
On Sunday, 3 May 2015 at 05:49:52 UTC, Andrei Alexandrescu wrote:
On 5/2/15 10:00 PM, Meta wrote:
It seems like it'd be a lot cheaper and cleaner to just be able to
alias
the parent method.
Yeh, that's the first solution that comes to mind. alias doesn't work
here but of course we could change the language.
Also, it could probably be made a bit simpler with
opDispatch.
I'd have to see the code, but my intuition is that things could get
quite a bit more hairy.
Andrei
IMO, using __traits and opDispatch is a fair bit cleaner, and I prefer
the syntax of a mixin template to regular mixin.
http://dpaste.dzfl.pl/d60498246577
You're right, that is lovely! I've improved it as follows:
mixin template forwardToMember(alias member, methods...)
{
import std.algorithm : among;
import std.traits : ParameterTypeTuple;
template opDispatch(string sym)
if ((methods.length == 0 || sym.among(methods)))
{
auto ref opDispatch(
ParameterTypeTuple!(__traits(getMember, member, sym)) args)
{
return __traits(getMember, member, sym)(args);
}
}
}
So now ref returns are preserved and the mixin is self-contained
(doesn't require imports from the outside).
Compared to my solution, this has the advantage that if the child
defines a method, it will take precedence over the formatted one. So
that allowed me to add a feature: if no methods are specified, all are
forwarded.
There are a couple of ways in which this could and should be improved,
most notably overloads control. Even as is it's pretty darn awesome,
Meta could you please make it into a pull request? I think it should go
in std.functional.
Take that back, the opDispatch-based solution has a fatal flaw: doesn't
compose properly. For example, in std.allocator it's frequent that
allocators stack on top of one another, so one forwards a method call to
another one which in turn forwards to another.
With code generation this obviously works out of the box because the
generated code is identical to what one would write by hand to achieve
the same. But the opDispatch-based solution only works one level.
Andrei
Re: The most awesome forward to member solution?
On 5/3/15 12:04 PM, Dicebot wrote: On Sunday, 3 May 2015 at 18:54:45 UTC, Andrei Alexandrescu wrote: I think it should go in std.functional. All similar utilities are currently in std.typecons worksforme -- Andrei
Re: The most awesome forward to member solution?
OK, here's what I have now - two templates that are self contained and
work well:
The first uses opDispatch to dispatch to a member. The second is a
simple string function that generates the appropriate code. As discussed
the latter composes but the former doesn't.
mixin template dispatchToMember(alias member, methods...)
{
import std.algorithm : among;
import std.traits : ParameterTypeTuple;
template opDispatch(string sym)
if ((methods.length == 0 || sym.among(methods)))
{
auto ref opDispatch(ParameterTypeTuple!(__traits(getMember,
member, sym)) args)
{
return __traits(getMember, member, sym)(args);
}
}
}
string forwardToMember(string member, string[] funs...)
{
string result = import std.traits : hasMember,
ParameterTypeTuple;\n;
foreach (fun; funs)
{
result ~=
static if (hasMember!(typeof(~member~), `~fun~`))
auto ~fun~(ParameterTypeTuple!(typeof(~member~.~fun~)) args)
{
return ~member~.~fun~(args);
}\n;
}
return result;
}
Andrei
Re: The most awesome forward to member solution?
On Sunday, 3 May 2015 at 20:25:45 UTC, Andrei Alexandrescu wrote: OK, here's what I have now - two templates that are self contained and work well: The first uses opDispatch to dispatch to a member. The second is a simple string function that generates the appropriate code. As discussed the latter composes but the former doesn't. I can't picture what you're talking about. Could you post an example?
Re: std.xml2 (collecting features)
On 5/3/2015 10:39 AM, Robert burner Schadek wrote: - CTS for encoding (ubyte(ASCII), char(utf8), ... ) Encoding schemes should be handled by adapter algorithms, not in the XML parser itself, which should only handle UTF8.
Re: std.xml2 (collecting features)
Can it lazily reads huge files (files greater than memory)?
Re: The most awesome forward to member solution?
On 5/3/15 4:20 PM, Meta wrote:
On Sunday, 3 May 2015 at 20:25:45 UTC, Andrei Alexandrescu wrote:
OK, here's what I have now - two templates that are self contained and
work well:
The first uses opDispatch to dispatch to a member. The second is a
simple string function that generates the appropriate code. As
discussed the latter composes but the former doesn't.
I can't picture what you're talking about. Could you post an example?
struct A
{
void fun(int);
}
struct B
{
A a;
mixin forwardToMember!(a, fun);
}
struct C
{
B b;
mixin forwardToMember!(b, fun);
}
Andrei
Adding a read primitive to ranges
Would it be a bad idea to add a read primitive to ranges for
streaming?
struct ReadRange(T){
size_t read(T[] buffer);
//and | or
T[] read(size_t request);
/+ empty,front,popFront,etc +/
}
Re: Classes. C++ to D
On Sunday, 3 May 2015 at 17:46:54 UTC, Meta wrote:
This is not really doable right now in D. You can forward the
function calls to a and b easily enough, but you can't inherit
from more than one class. Once the multiple alias this patch
gets merged you will be able to do this in D.
On Sunday, 3 May 2015 at 18:17:26 UTC, Adam D. Ruppe wrote:
I'd make class A and class B into mixin templates instead.
mixin template A {
string a() { return foo; }
}
mixin template B {
string b() { return bar; }
}
class C {
mixin A;
mixin B;
}
If you still need class A and class B, just make a class that
mixes in the template for them too.
Since the C++ methods aren't virtual, I imagine you don't
really need a base class for them, but if you do want a virtual
base class, make interfaces and inherit from as many of them as
you need.
Thanks.
On Sunday, 3 May 2015 at 20:03:00 UTC, QAston wrote:
If you want to learn a language properly, translating the idioms
directly from what you already know is a bad approach. You're
going to be frustrated that something was easy (to you) in your
old language and the new one is weird and different than the old
one. Also - results are often suboptimal.
I've seen this happen too many times to not warn you, but if you
just want to carry over and you don't care about learning or
quality of result then please carry on.
At the moment, I do not do a complete study of the D, so the
quality is not important to me. Start a complete study of D, I
plan a little later.
dmd -profile=gc
Just merged in is a new compiler switch that instruments generated code to collect statistics on memory allocation usage and generates a report upon program termination. (Much like how -profile works.) This was based on a prototype Andrei had written earlier. Andrei and I suspect it can be of great use in figuring out why a program may be excessively slow or consume excessive memory. I encourage giving it a try on some non-trivial project, and see if it gives useful information.
Re: std.xml2 (collecting features)
On 2015-05-03 17:39:46 +, Robert burner Schadek rburn...@gmail.com said: std.xml has been considered not up to specs nearly 3 years now. Time to build a successor. I currently plan the following featues for it: - SAX and DOM parser - in-situ / slicing parsing when possible (forward range?) - compile time switch (CTS) for lazy attribute parsing - CTS for encoding (ubyte(ASCII), char(utf8), ... ) - CTS for input validating - performance Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 Please post you feature requests, and please keep the posts DRY and on topic. This isn't a feature request (sorry?), but I just want to point out that you should feel free to borrow code from https://github.com/michelf/mfr-xml-d There's probably a lot you can reuse in there. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: std.xml2 (collecting features)
On Sunday, 3 May 2015 at 17:39:48 UTC, Robert burner Schadek wrote: std.xml has been considered not up to specs nearly 3 years now. Time to build a successor. I currently plan the following featues for it: - SAX and DOM parser - in-situ / slicing parsing when possible (forward range?) - compile time switch (CTS) for lazy attribute parsing - CTS for encoding (ubyte(ASCII), char(utf8), ... ) - CTS for input validating - performance Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 Please post you feature requests, and please keep the posts DRY and on topic. Could possibly use pegged to do it? It may simplify the parsing portion of it for you at least.
Re: std.xml2 (collecting features)
On 5/3/2015 10:39 AM, Robert burner Schadek wrote: Please post you feature requests, and please keep the posts DRY and on topic. Try to design the interface to it so it does not inherently require the implementation to allocate GC memory.
CTFE template predicates
Hi, I have now played a around couple of hours (reading everything I
could find) to get something to work, but I think I'm missing some
basic concepts/understanding. Maybe someone can enlighten me how these
things work. I thought that some code from David Nadlinger is what I'm
searching for but don't know how to exactly make use of it.
Here is the code: I want to filter out some of the allMembers and use
them in my code for a switch/final to check that call cases that were
not filtered are covered. Trying to build the enum for the switch/final
statement.
auto org_rules = TypeTuple!(__traits(allMembers,BolSource));
static assert(!isTypeTuple!(org_rules));
template startsNotWith(T,char C){
static if (T[0] != C){
enum startsNotWith = true;
} else {
enum startsNotWith = false;
}
}
template StaticFilter(alias pred, T...) {
static if (T.length == 0) {
alias TypeTuple!() StaticFilter;
} else static if (pred!(T[0])) {
alias TypeTuple!(T[0], StaticFilter!(pred, T[1 .. $])) StaticFilter;
} else {
alias StaticFilter!(pred, T[1 .. $]) StaticFilter;
}
}
alias startsNotWithp = startsNotWith!(T,p); // doesn't compile:
Error: undefined identifier T
alias rules = StaticFilter!(startsNotWithp, org_rules);
While playing with this a couple of questions came up:
1. How do predicates get their argument(s)? I saw code where only the
predicate was mentioned but no arguments. So, I assume there is some
behind-the-curtain-magic going on. I read about things like a == b
where I can reference 'a and 'b in a string.
2. enum startsNotwith = false So this is the return syntax for a CTFE
for return(true) ?
3. TupleType is a very missleading name when you are learning these
things, because the tuple can hold values as well. Or is there a more
extensive explanation for the name I don't get?
4. Are there any tutorials about CTFE? This seems to be a very powerful
but not so easy to use feature of D, but documentation is quite limited.
Thanks a lot.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: std.xml2 (collecting features)
On 5/3/2015 2:31 PM, Ilya Yaroshenko wrote: Can it lazily reads huge files (files greater than memory)? If a range interface is used, it doesn't need to be aware of where the data is coming from. In fact, the xml package should NOT be doing I/O.
Re: CTFE template predicates
On Sunday, 3 May 2015 at 21:46:11 UTC, Robert M. Münch wrote:
Hi, I have now played a around couple of hours (reading
everything I could find) to get something to work, but I think
I'm missing some basic concepts/understanding. Maybe someone
can enlighten me how these things work. I thought that some
code from David Nadlinger is what I'm searching for but don't
know how to exactly make use of it.
Here is the code: I want to filter out some of the allMembers
and use them in my code for a switch/final to check that call
cases that were not filtered are covered. Trying to build the
enum for the switch/final statement.
auto org_rules = TypeTuple!(__traits(allMembers,BolSource));
static assert(!isTypeTuple!(org_rules));
template startsNotWith(T,char C){
static if (T[0] != C){
enum startsNotWith = true;
} else {
enum startsNotWith = false;
}
}
Here T would have to be a type. But you want to accept a string.
So:
template startsNotWith(string s,char c){
enum startsNotWith = s.length == 0 || s[0] != c;
}
template StaticFilter(alias pred, T...) {
static if (T.length == 0) {
alias TypeTuple!() StaticFilter;
} else static if (pred!(T[0])) {
alias TypeTuple!(T[0], StaticFilter!(pred, T[1 .. $]))
StaticFilter;
} else {
alias StaticFilter!(pred, T[1 .. $]) StaticFilter;
}
}
alias startsNotWithp = startsNotWith!(T,p); // doesn't
compile: Error: undefined identifier T
You need to turn T into a parameter, so that StaticFilter can set
it. (And it's really a string again, so I'm renaming to s.)
template startsNotWithp(string s)
{
enum startsNotWithp = startsNotWith!(s, 'p');
}
/* Shorthand syntax: enum startsNotWithp(string s) =
startsNotWith!(s, 'p'); */
alias rules = StaticFilter!(startsNotWithp, org_rules);
While playing with this a couple of questions came up:
1. How do predicates get their argument(s)? I saw code where
only the predicate was mentioned but no arguments. So, I assume
there is some behind-the-curtain-magic going on. I read about
things like a == b where I can reference 'a and 'b in a
string.
Predicates are called/instantiated by the thing to which you pass
them. StaticFilter instantiates pred for each element of the T
tuple it's given. If some documentation doesn't say how the
predicate will be called/instantiated, then it's probably assumed
to be obvious.
String predicates are turned into functions behind the curtains.
The thing you instantiate with a == b turns it into `(a, b)
{return a == b;}` and uses that. I think we don't do string
predicates for templates like StaticFilter, though.
2. enum startsNotwith = false So this is the return syntax
for a CTFE for return(true) ?
It's the template syntax for return false. CTFE does normal
functions at compile time, so there it's just return false.
/* Template: */
template t() {enum t = false;}
enum x = t!();
/* CTFE: */
bool f() {return false;}
enum y = f();
3. TupleType is a very missleading name when you are learning
these things, because the tuple can hold values as well.
Yup. And std.traits.isTypeTuple only adds to the confusion.
Or is there a more extensive explanation for the name I don't
get?
Not that I'm aware of.
4. Are there any tutorials about CTFE? This seems to be a very
powerful but not so easy to use feature of D, but documentation
is quite limited.
CTFE is rather simple. It just allows you to use certain
functions in a static (i.e. compile time) context.
Templates are more tricky. If you mean templates, maybe having
the right name helps.
Re: CTFE template predicates
On Sunday, 3 May 2015 at 21:46:11 UTC, Robert M. Münch wrote: 3. TupleType is a very missleading name when you are learning these things, because the tuple can hold values as well. Or is there a more extensive explanation for the name I don't get? Legacy we are trying to get rid of. See also: https://github.com/D-Programming-Language/phobos/pull/3128 https://github.com/D-Programming-Language/dlang.org/pull/986
Is this expected? default to public members in private class
It seems a private class or struct defaults to public members. Just
curious if this is intended. I would have expected private all the way
down unless overriden.
--- plugh.d
module plugh;
auto makeFoo() {return new Foo;}
private:
class Foo
{
void maybepriv() {}
private void priv() {}
public void pub() {}
}
--- xyzzy.d
module xyzzy;
import plugh;
void main()
{
auto f = makeFoo();
f.maybepriv(); // is accessible after all
//f.priv(); // err expected, member private
f.pub();
}
--
Dan Olson
Struct lifetime wrt function return?
I remember reading that guaranteed RVO was part of the D
standard, but I am completely unable to find anything on it in
the specification.
I'm also unable to find anything in it that explicitly states the
lifetime of returning a stack-local struct from a function.
However, it does state
Destructors are called when an object goes out of scope.
So without guaranteed RVO I am quite confused.
I apologize because this code will likely be poorly formatted.
import std.stdio;
struct S{
~this(){
writeln(Goodbye!);
}
}
S foo(){
S s;
return s;
}
void main()
{
S s2 = foo();
}
This says Goodbye! exactly once, indicating(?) that S was
NRVO'd which means the scope of s went from foo to main.
However, is this a guarantee by the standard? Is an
implementation allowed to define foo such that it returns by copy
and calls a destructor on s, meaning Goodbye! would print out
twice?
Converting (casting?) a dynamic array to a fixed array?
This following code works fine. A triangle is displayed. GLfloat[6] verts = [ 0.0, 1.0, -1.0, -1.0, 1.0, -1.0 ]; glGenBuffers(1, vbo); glBindBuffer(GL_ARRAY_BUFFER, vbo); // Some of the types are: glBufferData(GL_ARRAY_BUFFER, verts.sizeof, verts, GL_STATIC_DRAW); Then, all I do is take out the 6 so that the static array becomes a dynamic one. It compiles fine. GLfloat[] verts = [ 0.0, 1.0, -1.0, -1.0, 1.0, -1.0 ]; However, when I run it, the triangle disappears. According to OpenGL, glBufferData shows: void glBufferData( ignore, GLsizeiptr size, const GLvoid * data, ignore); So I thought the best solution would be to simply cast the dynamic array to a pointer? So I tried: glBufferData(GL_ARRAY_BUFFER, verts.sizeof, cast(const GLvoid *) verts, GL_STATIC_DRAW); and glBufferData(GL_ARRAY_BUFFER, verts.sizeof, cast(const GLvoid *) verts, GL_STATIC_DRAW); and glBufferData(GL_ARRAY_BUFFER, verts.sizeof, verts.ptr, GL_STATIC_DRAW); and glBufferData(GL_ARRAY_BUFFER, verts.sizeof, cast(const GLvoid *) verts.ptr, GL_STATIC_DRAW); and nothing but more blank screens. Any ideas? Thanks.
Re: Converting (casting?) a dynamic array to a fixed array?
On Monday, 4 May 2015 at 02:47:24 UTC, WhatMeWorry wrote:
glBufferData(GL_ARRAY_BUFFER, verts.sizeof, verts,
GL_STATIC_DRAW);
Try
(GL_ARRAY_BUFFER, verts.length, verts.ptr, GL_STATIC_DRAW)
or maybe:
(GL_ARRAY_BUFFER, verts.length * verts[0].sizeof, verts.ptr,
GL_STATIC_DRAW)
I'm not sure exactly what the function needs, but using the
.length and .ptr properties on a dynamic array will probably work
better than casting, and definitely work better than casting the
address of it. (A dynamic array is actually a struct { size_t
length; T* ptr; } object instead of raw memory like a static
array, so taking the address of it actually gives the address of
that length variable, not the data. the ptr attribute gets the
pointer to the data. BTW static arrays also have .length and .ptr
properties you can use the same way.)
Re: Converting (casting?) a dynamic array to a fixed array?
On Monday, 4 May 2015 at 02:47:24 UTC, WhatMeWorry wrote: This following code works fine. A triangle is displayed. GLfloat[6] verts = [ 0.0, 1.0, -1.0, -1.0, 1.0, -1.0 ]; glGenBuffers(1, vbo); glBindBuffer(GL_ARRAY_BUFFER, vbo); // Some of the types are: glBufferData(GL_ARRAY_BUFFER, verts.sizeof, verts, GL_STATIC_DRAW); Then, all I do is take out the 6 so that the static array becomes a dynamic one. It compiles fine. GLfloat[] verts = [ 0.0, 1.0, -1.0, -1.0, 1.0, -1.0 ]; However, when I run it, the triangle disappears. According to OpenGL, glBufferData shows: void glBufferData( ignore, GLsizeiptr size, const GLvoid * data, ignore); So I thought the best solution would be to simply cast the dynamic array to a pointer? So I tried: glBufferData(GL_ARRAY_BUFFER, verts.sizeof, cast(const GLvoid *) verts, GL_STATIC_DRAW); and glBufferData(GL_ARRAY_BUFFER, verts.sizeof, cast(const GLvoid *) verts, GL_STATIC_DRAW); and glBufferData(GL_ARRAY_BUFFER, verts.sizeof, verts.ptr, GL_STATIC_DRAW); and glBufferData(GL_ARRAY_BUFFER, verts.sizeof, cast(const GLvoid *) verts.ptr, GL_STATIC_DRAW); and nothing but more blank screens. Any ideas? Thanks. sizeof on a slice doesn't do what you think it does, it returns the size of the actual slice object I believe.
Re: Efficiently passing structs
On Sunday, May 03, 2015 21:58:12 bitwise via Digitalmars-d-learn wrote:
If I have a large struct that needs to be passed around, like a 4x4 matrix
for example, how do I do that efficiently in D?
In std.datetime, in is used for most struct parameters, but I'm confused
by the docs for function parameter storage classes[1].
In C++, I would pass a large struct as (const):
void foo(const Matrix4x4 m);
Is in in D the same as passing by const in C++? The documentation
doesn't say anything about in being a reference, but it doesn't say that
out parameters are references either, even though it's usage in the
example clearly shows that it is.
Thanks,
Bit
http://dlang.org/function.html#parameters
std.datetime's use of in is pointless and really should be removed. I
misunderstood it at the time I did that. in is essentially an alias for
const scope, and scope does nothing in most cases, basically making it
const, which is generally pointless for a function parameter unless you're
specifically trying to make it so that it can't be mutated inside the
function. And since scope has not even been properly designed (let alone
implemented), I would argue that using in is almost always a bad idea.
The equivalent to const in D is const ref except that it does not accept
rvalues. So, if you want to be able to do the same, you'll have to do
something like
void foo(ref const Matrix4x4 m)
{
...
}
void foo(const Matrix4x4 m)
{
foo(m);
}
D will move the argument if it can rather than copying it (e.g. if a
temporary is being passed in), which reduces the need for worrying about
copying like you tend to have to do in C++98, and I think that a lot of D
code just doesn't worry about the cost of copying structs. However, if you
have a large object that you know is going to be expensive to copy, you're
either going to have to use const ref (and thus probably duplicate the
function to allow rvalues), or you're going to need to make it a reference
type rather than having all of its data live on the stack (either by making
it so that the struct contains a pointer to its data or by making it a
class). In general, if you're dealing with a type that is going to be
expensive to copy, I'd advise making it a reference type over relying on
const ref simply because it's less error-prone that way. It's trivial to
forget to use ref on a parameter, and generic code won't use it, so it'll
generally work better to just make it a reference type.
- Jonathan M Davis
[Issue 11003] Improve .di generation
https://issues.dlang.org/show_bug.cgi?id=11003
--- Comment #3 from Kenji Hara k.hara...@gmail.com ---
One more case:
enum isInt(T) = is(T == int);
For that, the generated di still uses old verbose style:
template isInt(T)
{
enum isInt = is(T == int);
}
--
https://github.com/D-Programming-Language/dmd/pull/4629
--
Re: This Week in D #15: hackathon, mem management, ARM, tip for C coders
On Mon, 04 May 2015 03:23:07 +, Adam D. Ruppe wrote: So I guess it is more a peeve of mine than anything else, but I wanted to talk about it anyway and used the tip of the week as my vehicle. D code that looks like C isn't a bad thing, indeed, I think it is a selling point. i found that i can write code in C style first, and then gradually converting it to be more D-like. btw, it's a great way to start using D for begginers with C expirience: just do it as you are used to, and then change some parts as you learned new trick. it's very useful when converting C libraries to D. i have some libraries that is hard/impractical to rewrite from scratch in D, but i want 'em in D to ease hacking and improving. so i'm first converting code using D as better C, and then adding better interfaces or rewriting some parts. signature.asc Description: PGP signature
Re: What wrong?
On Saturday, 2 May 2015 at 20:46:32 UTC, Dennis Ritchie wrote: On Saturday, 2 May 2015 at 19:38:01 UTC, Fyodor Ustinov wrote: I see it by the lack of 42. :) But why is this receive breaks down? Report, please, about it (D)evepopers :) https://issues.dlang.org/ I'm not sure that it's not my fault. So I hope that will come by knowledgeable people and say Hey, buddy, your mistake is... :)
[Issue 277] Named mixin operator resolution
https://issues.dlang.org/show_bug.cgi?id=277 Vlad Levenfeld vlevenf...@gmail.com changed: What|Removed |Added CC||vlevenf...@gmail.com --
Re: Efficiently passing structs
On Monday, 4 May 2015 at 01:58:12 UTC, bitwise wrote: The documentation doesn't say anything about in being a reference, but it doesn't say that out parameters are references either, even though it's usage in the example clearly shows that it is. Thanks, Bit http://dlang.org/function.html#parameters it's specified in http://dlang.org/abi.html (at the bottom): out and ref are passed as pointers. The logic seems to be that if it's not specified then it's copied. Maybe `const ref` is what you're looking for...passed as pointer but the compiler will prevent writing the parameter, though it's still possible to take the address and to modify the param if the function is not @safe.
Re: Adding a read primitive to ranges
On Mon, 04 May 2015 00:07:25 +, Freddy wrote:
Would it be a bad idea to add a read primitive to ranges for streaming?
struct ReadRange(T){
size_t read(T[] buffer); //and | or T[] read(size_t request);
/+ empty,front,popFront,etc +/
}
if you want to add such things, i'd say you should model that by
`std.stdio.File` (`rawRead`, `rawWrite` and other file functions).
i'm using my `streams` module that uses such interfaces for a long time.
can't see why it should be range, though. i introduced Stream entity,
which, like range, can be checked with various traits: isReadableStream,
isWriteableStream, isSeekableStream and so on. note that stream can be
range too, that's completely different interfaces.
what is good with taking `std.stdio.File` as a base -- all my stream
operations immediately usable on standard file objects from Phobos.
signature.asc
Description: PGP signature
Re: Struct lifetime wrt function return?
On Mon, 04 May 2015 02:29:19 +, rsw0x wrote: This says Goodbye! exactly once, indicating(?) that S was NRVO'd which means the scope of s went from foo to main. However, is this a guarantee by the standard? Is an implementation allowed to define foo such that it returns by copy and calls a destructor on s, meaning Goodbye! would print out twice? actually, you'd better avoid code that makes assumptions about struct copying/moving. compiler is free to do what it sees better. moreover, phobos can use moving too. but it also can use copy/destroy. what i want to say is that you should write your code with structure copying in mind. remember that structure is value type, it can be freely moved and copied. you can also explicitly disable structure copying with @disable this (this); and if you concerned about code optimisation... well, NRVO is guaranteed in DMD, and recent GDC got it too. don't know about LDC, though, but you can expect that NRVO is guaranteed, yes. if new compiler will appear (SDC, for example), i think that it will do NRVO too (sooner or later). signature.asc Description: PGP signature
Re: Is it safe to reset HOLD fiber?
On Sunday, 3 May 2015 at 14:36:04 UTC, Martin Nowak wrote: On Sunday, 3 May 2015 at 12:33:36 UTC, Dzugaru wrote: Actually the documentation answers your question, please help to improve it if you don't find it clear enough. http://dlang.org/phobos/core_thread.html#.Fiber.reset Created a pull request with your answer added to a Fiber reset method description. In my opinion it should be either disallowed to reset the fiber in a HOLD state or clearly documented that stack wont be cleaned. I'm dreaded to think about random crashes in my app some hours after launch because of fiber reusing. Also, I'm not familiar with contract programming, but shouldn't the in body clause be included in all overloads of a reset, not just first? Now I'm thinking about how to do unfinished fiber reusing properly. Adding if(!isFibTerminated) return; after every Fiber.yield() is not good :(
Re: The most awesome forward to member solution?
On Monday, 4 May 2015 at 01:01:05 UTC, Andrei Alexandrescu wrote: Hmm, I didn't try it assuming it won't work (thought __traits(getMember, member, sym) would fail with opDispatch). Tried it just now, it does work like a charm. Thanks! Andrei So is a function that generates a string mixin necessary or not necessary?
This Week in D #15: hackathon, mem management, ARM, tip for C coders
I covered two weeks this time, as I missed last week. http://arsdnet.net/this-week-in-d/may-03.html The tip this week might be a bit controversial but I actually feel kinda strongly about this. So many times, I see people asking questions about how to do task X in D. I think that's the wrong question: you should just be asking how to do task X. The programming language isn't terribly important: if you can do it in C, you can do it in D basically the same way; D provides similar language features to other common languages like C and Java, so a LOT of knowledge carries over from them... as long as you aren't afraid to use it. I think that when people are new to D, we ought to press this carry-over point. They don't have to forget everything and suddenly do everything the D way, using only Phobos, doing it all with lazy ranges, etc. It doesn't have to be all that new, unfamiliar territory at once. Similarly, I get a bit bothered when I see a lot of work done to add a bit of common functionality to a C library. Now, don't get me wrong, I reinvent the wheel as much as the next guy (actually, I don't even like the term reinventing the wheel exactly because so much knowledge carries over. Just because I'm re-coding it doesn't mean I'm reinventing it. By carrying over knowledge of the problem domain from any source, it makes coding it again a lot easier - I already know what needs to be done and where the pitfalls are, unlike a truly novel invention, where all that is a mystery going into it. But I digress). I almost never use third party libraries personally for a variety of reasons, so I get the desire to rewrite things, especially when D offers so many ways to do it better than ever before. But at the same time, I'm also a working programmer accustomed to things like last-minute client requests, deadlines, and other schedule constraints (including just simply not *wanting* to spend that kind of time on a problem, believe it or not, I don't actually care for programming all day every day) In these cases, being able to say yes we can, and I can do it today, though it might look like C is so much more valuable than saying maybe... if I figure out how to make it idiomatic D So I guess it is more a peeve of mine than anything else, but I wanted to talk about it anyway and used the tip of the week as my vehicle. D code that looks like C isn't a bad thing, indeed, I think it is a selling point.
Re: Efficiently passing structs
On Monday, 4 May 2015 at 03:57:04 UTC, bitwise wrote: I'll probably go with in ref. I think escape proof is probably a good default. Not to mention, easier to type ;) FYI I'm unsure how well `scope` storage class is currently implemented because it's in a state of flux at the moment as far as I know. `in ref` still helps document your intent of the parameter however. It's hard to track this down exactly because scope has so many different meanings in D, making it difficult to search for - at least one of them has been deprecated.
Re: The most awesome forward to member solution?
On 5/3/15 8:13 PM, Meta wrote: On Monday, 4 May 2015 at 01:01:05 UTC, Andrei Alexandrescu wrote: Hmm, I didn't try it assuming it won't work (thought __traits(getMember, member, sym) would fail with opDispatch). Tried it just now, it does work like a charm. Thanks! Andrei So is a function that generates a string mixin necessary or not necessary? I'm not sure. It's a great question. In some ways a string mixin is the straight deal - you get complete control over what you generate, ultimate flexibility, and you get to inspect it if you so want. (BTW I think compiler errors in mixins should either print the failing mixin with line numbers, or make it available as a file). But then the opDispatch solution is more structured and restricted in a good way. I think we need a bit more experience with both to figure out which is the best way to go. More specifically: * forward to enumerated types * distinguish static/non-static methods, and define forwarding appropriately * define properties to forward to member variables * alias member types and templates * other similar stuff I didn't think of, in essence defer stuff to this member Andrei
Re: A slice can lose capacity simply by calling a function
On Sunday, May 03, 2015 15:21:15 Andrew Godfrey via Digitalmars-d-learn wrote: I really don't think that it's an issue in general, but if you do want to guarantee that nothing affects the capacity of your array, then you're going to need to either wrap all access to it I agree with everything Jonathan said in both threads EXCEPT that this is not an issue. The syntax slice.capacity gives the impression that 'capacity' is a property of the slice. Such lack of consistency is a SERIOUS issue for D, especially when it occurs in something as basic as an array. I really don't see the problem. It's a natural side effect of how dynamic arrays work in D. The only thing I can see that could be changed without losing some of the capabilities that we currently have is if capacity were explicitly a separate function - e.g. calcArrayCapacity - but I really don't think that that would buy us much. You'd still have to understand how D's dynamic arrays work to understand how the capacity for a dynamic array works. And most code really doesn't care about the capacity of an array. If you profile and find that appending to an array is a hot spot in your program, then you dig in and use reserve or Appender or use something other than a naked array, and you figure out what works best for your particular use case, but for most code, it just works to use ~=. And if you're concerned about reallocations even before profiling, then it's trivial to just call reserve first or to use Appender. And unless you're doing something like constantly slicing and appending to each slice (which I expect to be a rare thing to do), you're really not going to run into problems. Sure, the semantics of D's dynamic arrays take some getting used to - especially if you want to understand all of their ins and outs. But I really don't see why it's a big problem. For the most part, D's dynamic arrays just work. - Jonathan M Davis
Re: The most awesome forward to member solution?
On 5/3/15 5:29 PM, Meta wrote:
On Sunday, 3 May 2015 at 23:54:49 UTC, Andrei Alexandrescu wrote:
On 5/3/15 4:20 PM, Meta wrote:
On Sunday, 3 May 2015 at 20:25:45 UTC, Andrei Alexandrescu wrote:
OK, here's what I have now - two templates that are self contained and
work well:
The first uses opDispatch to dispatch to a member. The second is a
simple string function that generates the appropriate code. As
discussed the latter composes but the former doesn't.
I can't picture what you're talking about. Could you post an example?
struct A
{
void fun(int);
}
struct B
{
A a;
mixin forwardToMember!(a, fun);
}
struct C
{
B b;
mixin forwardToMember!(b, fun);
}
Andrei
I still don't get it. Your example works with both dispatchToMember and
forwardToMember. What is the difference between these two exactly?
auto opDispatch(string sym: foo)(ParemeterTypeTuple!(/*etc*/) args)
{
return parent.foo(args);
}
//Automatically generated
auto foo(ParameterTypeTuple!(/*etc*/) args)
{
return parent.foo(args);
}
Hmm, I didn't try it assuming it won't work (thought __traits(getMember,
member, sym) would fail with opDispatch). Tried it just now, it does
work like a charm. Thanks!
Andrei
Re: What wrong?
On Monday, 4 May 2015 at 01:03:43 UTC, Fyodor Ustinov wrote: I'm not sure that it's not my fault. So I hope that will come by knowledgeable people and say Hey, buddy, your mistake is... :) OK. But if one does not come within three days :), duplicate topic in this section: http://forum.dlang.org/group/digitalmars.D
Efficiently passing structs
If I have a large struct that needs to be passed around, like a 4x4 matrix for example, how do I do that efficiently in D? In std.datetime, in is used for most struct parameters, but I'm confused by the docs for function parameter storage classes[1]. In C++, I would pass a large struct as (const): void foo(const Matrix4x4 m); Is in in D the same as passing by const in C++? The documentation doesn't say anything about in being a reference, but it doesn't say that out parameters are references either, even though it's usage in the example clearly shows that it is. Thanks, Bit http://dlang.org/function.html#parameters
[Issue 14542] New: Table of contents in specification PDF is broken
https://issues.dlang.org/show_bug.cgi?id=14542 Issue ID: 14542 Summary: Table of contents in specification PDF is broken Product: D Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: r9shacklef...@gmail.com Created attachment 1518 -- https://issues.dlang.org/attachment.cgi?id=1518action=edit TOC Screenshot of brokenness is attached, table of contents is generating garbage. --
Re: Efficiently passing structs
On Monday, 4 May 2015 at 01:58:12 UTC, bitwise wrote: If I have a large struct that needs to be passed around, like a 4x4 matrix for example, how do I do that efficiently in D? In std.datetime, in is used for most struct parameters, but I'm confused by the docs for function parameter storage classes[1]. In C++, I would pass a large struct as (const): void foo(const Matrix4x4 m); Is in in D the same as passing by const in C++? The documentation doesn't say anything about in being a reference, but it doesn't say that out parameters are references either, even though it's usage in the example clearly shows that it is. Thanks, Bit http://dlang.org/function.html#parameters Use the ref storage class. You can use more than one storage class i.e, foo(in ref int x) Unless I misunderstood you.
Re: CTFE template predicates
On 4/05/2015 9:46 a.m., Robert M. Münch wrote:
Hi, I have now played a around couple of hours (reading everything I
could find) to get something to work, but I think I'm missing some basic
concepts/understanding. Maybe someone can enlighten me how these things
work. I thought that some code from David Nadlinger is what I'm
searching for but don't know how to exactly make use of it.
Here is the code: I want to filter out some of the allMembers and use
them in my code for a switch/final to check that call cases that were
not filtered are covered. Trying to build the enum for the switch/final
statement.
auto org_rules = TypeTuple!(__traits(allMembers,BolSource));
static assert(!isTypeTuple!(org_rules));
template startsNotWith(T,char C){
static if (T[0] != C){
enum startsNotWith = true;
} else {
enum startsNotWith = false;
}
}
template StaticFilter(alias pred, T...) {
static if (T.length == 0) {
alias TypeTuple!() StaticFilter;
} else static if (pred!(T[0])) {
alias TypeTuple!(T[0], StaticFilter!(pred, T[1 .. $])) StaticFilter;
} else {
alias StaticFilter!(pred, T[1 .. $]) StaticFilter;
}
}
alias startsNotWithp = startsNotWith!(T,p); // doesn't compile: Error:
undefined identifier T
alias rules = StaticFilter!(startsNotWithp, org_rules);
While playing with this a couple of questions came up:
1. How do predicates get their argument(s)? I saw code where only the
predicate was mentioned but no arguments. So, I assume there is some
behind-the-curtain-magic going on. I read about things like a == b
where I can reference 'a and 'b in a string.
2. enum startsNotwith = false So this is the return syntax for a CTFE
for return(true) ?
3. TupleType is a very missleading name when you are learning these
things, because the tuple can hold values as well. Or is there a more
extensive explanation for the name I don't get?
4. Are there any tutorials about CTFE? This seems to be a very powerful
but not so easy to use feature of D, but documentation is quite limited.
Thanks a lot.
Have you looked at my book? https://leanpub.com/ctfe
Re: Efficiently passing structs
On Sun, 03 May 2015 22:37:52 -0400, rsw0x anonym...@anonymous.com wrote: Use the ref storage class. You can use more than one storage class i.e, foo(in ref int x) Thanks, this should work. On Sun, 03 May 2015 23:29:59 -0400, Baz bb.t...@gmx.com wrote: it's specified in http://dlang.org/abi.html (at the bottom): out and ref are passed as pointers. Awesome, thanks for the link. Maybe `const ref` is what you're looking for... I'll probably go with in ref. I think escape proof is probably a good default. Not to mention, easier to type ;)
Re: std.xml2 (collecting features)
On 4/05/2015 5:39 a.m., Robert burner Schadek wrote: std.xml has been considered not up to specs nearly 3 years now. Time to build a successor. I currently plan the following featues for it: - SAX and DOM parser - in-situ / slicing parsing when possible (forward range?) - compile time switch (CTS) for lazy attribute parsing - CTS for encoding (ubyte(ASCII), char(utf8), ... ) - CTS for input validating - performance Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 Please post you feature requests, and please keep the posts DRY and on topic. Preferably the interfaces are made first 1:1 as the spec requires. Then its just a matter of building the actual reader/writer code. That way we could theoretically rewrite the reader/writer to support other formats such as html5/svg. Independently of phobos. Also would be nice to be CTFE'able!
Re: Is this expected? default to public members in private class
On Sun, 03 May 2015 18:07:20 -0700, Dan Olson wrote: It seems a private class or struct defaults to public members. Just curious if this is intended. I would have expected private all the way down unless overriden. i bet it is intended. protection of struct/class members is independed of protection of struct/class itself. this is good for code consistency: no changing of outer protection flags can alter struct/class inner machinery. so if you changed your mind about protection level of some global things, you shouldn't unnecessary fix your code in completely unrelated places. signature.asc Description: PGP signature
Re: UDA and ReturnType!(__traits...) doesn't work
On Sun, 03 May 2015 18:02:37 +, filcuc wrote: Yep sorry, i'm still learning :) i'm not blaming you at all. what i mean i that i'm bad at explanations, so you'd better read one of the D books to better understand my cryptic don't do that, do this comments. ;-) signature.asc Description: PGP signature
Re: Building DMD on SmartOS
On Sunday, 3 May 2015 at 07:04:17 UTC, Joakim wrote: On Thursday, 30 April 2015 at 17:39:02 UTC, flamencofantasy wrote: Hello, I would like to use D on SmartOS. Since there is no binary installer I tried to build DMD from source by following the instructions on this page; http://wiki.dlang.org/Building_DMD Unfortunately I get this error; [~/d/dmd/src]# make -f posix.mak MODEL=64 no cpu specified, assuming X86 dmd idgen.d make: dmd: Command not found posix.mak:320: recipe for target 'idgen' failed make: *** [idgen] Error 127 I spent a couple hours and installed SmartOS in a VM, my first time ever messing with SmartOS though I've run and developed for Solaris before, to see what the status of building dmd is. While it was a pain getting SmartOS configured, I was finally able to build dmd 2.067 and druntime without a problem, using gcc 4.7 (the clang from pkgin tried to use some linker config that wouldn't work to link even basic test C++ files). Phobos now keeps failing to build on me, but only because I'm low on disk space and it keeps running out of swap. However, linking a small sample file against druntime alone fails, some issue with the deh_beg/deh_end sections: gcc sieve.o ./lib/libdruntime-solaris64.a -o sieve -m64 -lpthread -lm ld: fatal: symbol '_deh_beg' in file sieve.o: section [15].deh_beg: size 0: symbol (address 0, size 0x4) lies outside of containing section ld: fatal: symbol '_deh_end' in file sieve.o: section [17].deh_end: size 0: symbol (address 0, size 0x4) lies outside of containing section ld: fatal: file processing errors. No output written to sieve collect2: error: ld returned 1 exit status I'll finish building phobos and mess around a bit with fixing those sections. I'll let you know if I get it to work. I got the some error. You need a more recent binutils version. Regards, Kai
Re: The most awesome forward to member solution?
On 2015-05-03 06:20, Andrei Alexandrescu wrote: Is this a common thing people wanna do? Put in Phobos? Yes, I would think so. Although, I would prefer a regular template mixin and taking the member as an alias parameter instead of a string, if possible. -- /Jacob Carlborg
Re: Closure capture loop variables
On Saturday, 2 May 2015 at 18:02:34 UTC, Idan Arye wrote: On Friday, 1 May 2015 at 21:42:22 UTC, deadalnix wrote: On Friday, 1 May 2015 at 17:51:05 UTC, Walter Bright wrote: On 4/30/2015 5:55 AM, Vladimir Panteleev wrote: I think Freddy's programs are working as designed. Yes, they are. D closures capture variables by reference. No, we're not changing that. The variable is declared in the block, therefore it is a DIFFERENT variable at every iteration. This or delegate are unable to respect constness/immutability. Conceptually - I agree. The variables declared in the block are different on each iteration, and I seriously doubt anyone escaping references to them(be it by closure or by direct pointer) means the same variable in all the iterations. Pragmatically - I'm not sure if this should be changed. This problem only appears when the closure escapes the scope - which from my experience seems to be the less common case. Unless the compiler can accurately tell when a closure escapes it's scope and when it doesn't, doing the correct thing will mean allocating call-stack frames on the heap *for every iteration* when a closure captures variable inside a loop. This can be a big hit on performance in the majority of the cases where it isn't really needed... It's trivial to check for escaping with a low false-positive rate. And even if not - correctness comes before performance.
Desktopfile library
dub package: http://code.dlang.org/packages/desktopfile Implementation of Desktop Entry Specification in D. Note that currently it's not fully compliant to spec, though it should work in the most cases.
[Issue 14539] New: +508KB (684KB - 1191KB) filesize increase Hello, world binary
https://issues.dlang.org/show_bug.cgi?id=14539 Issue ID: 14539 Summary: +508KB (684KB - 1191KB) filesize increase Hello, world binary Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: regression Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com https://github.com/D-Programming-Language/phobos/pull/2956#issuecomment-98484651 --
Re: Read and write gzip files easily.
And there is Zipios++ http://zipios.sourceforge.net/ On Sun, 2015-05-03 at 14:33 +, via Digitalmars-d wrote: On Thursday, 20 February 2014 at 10:35:50 UTC, Stephan Schiffels wrote: Hi Kamil, I am glad someone has the exact same problem as I had. I actually solved this, inspired by the python API you quoted above. I wrote these classes: GzipInputRange, GzipByLine, and GzipOut. Here is how I can now use them: I've polished your module a bit at: https://github.com/nordlow/justd/blob/611ae3aac35a085af966e0c3b717deb 0012f637b/zio.d Reflections: - Performance is terrible even with -release -noboundscheck -unittest. About 20 times slower than zcat $F | wc -l. I'm guessing _chunkRange.front.dup slows things down. I tried removing the .dup but then I get std.zlib.ZlibException@std/zlib.d(59): data error I don't believe we should have to do a copy of _chunkRange.front but I can't figure out how to solve it. Anybody understands how to fix this? - Shouldn't GzipOut.finish() call this.close()? Otherwise the file remains unflushed. - And what about calling this.close() in GzipOut.~this()? Is that needed to? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: A slice can lose capacity simply by calling a function
I really don't think that it's an issue in general, but if you do want to guarantee that nothing affects the capacity of your array, then you're going to need to either wrap all access to it I agree with everything Jonathan said in both threads EXCEPT that this is not an issue. The syntax slice.capacity gives the impression that 'capacity' is a property of the slice. Such lack of consistency is a SERIOUS issue for D, especially when it occurs in something as basic as an array. One other place I see this problem is the semantics of utf8 strings. This is DEADLY for D adoption. Personally, I think I'll be trying out Rust now, and checking back on these two issues later. This makes me sad, D is so promising ... but unfortunately the high standards it sets in many areas, are completely undercut by such basic problems. I work on large systems, and I can't imagine building a large system in this state.
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 13:20:03 UTC, cym13 wrote: I got a parsererror for data/data.json, Unrecognized token '?' Please try Chrome or Firefox.
Re: Read and write gzip files easily.
On Thursday, 20 February 2014 at 10:35:50 UTC, Stephan Schiffels wrote: Hi Kamil, I am glad someone has the exact same problem as I had. I actually solved this, inspired by the python API you quoted above. I wrote these classes: GzipInputRange, GzipByLine, and GzipOut. Here is how I can now use them: I've polished your module a bit at: https://github.com/nordlow/justd/blob/611ae3aac35a085af966e0c3b717deb0012f637b/zio.d Reflections: - Performance is terrible even with -release -noboundscheck -unittest. About 20 times slower than zcat $F | wc -l. I'm guessing _chunkRange.front.dup slows things down. I tried removing the .dup but then I get std.zlib.ZlibException@std/zlib.d(59): data error I don't believe we should have to do a copy of _chunkRange.front but I can't figure out how to solve it. Anybody understands how to fix this? - Shouldn't GzipOut.finish() call this.close()? Otherwise the file remains unflushed. - And what about calling this.close() in GzipOut.~this()? Is that needed to?
Re: Is it safe to reset HOLD fiber?
On Sunday, 3 May 2015 at 12:42:23 UTC, Dzugaru wrote: Just did another test and it seems its not safe at all. Reusing the fibers with reset without properly exiting the function leads to eventual stack overflow. It won't cleanup the old stack, so it may leak resources. It will properly reset the stack though, so the fiber should behave like a new one.
[Issue 14523] New Windows Application uses incorrect initialization/termination code
https://issues.dlang.org/show_bug.cgi?id=14523 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de --- Thanks for reporting. It will be updated in the next release. --
Re: Merging one Array with Another
On Saturday, 2 May 2015 at 04:08:04 UTC, Ali Çehreli wrote: Interesting idea. I have defined a simple algorithm below to see how it could work (my skipped() function instead of uniq()). That's a bit above my current D experience to decide. What about just tweaking uniq() for now to propagate SortedRange and leave the rest for later? Or will this break existing uses of uniq?
Re: D 2.067.1
On Sunday, 26 April 2015 at 17:53:07 UTC, Martin Nowak wrote: We're glad to announce dmd 2.067.1 which includes several regression and bug fixes over 2.067.0. http://dlang.org/changelog.html#2.067.1 Please report any bug you encounter at https://issues.dlang.org/. travis-ci still uses DMD64 D Compiler v2.067.0 on default and not the latest. where can one submit a PR for this ?
Re: std.random question
import std.random;
struct Mystruct {
int id;
static opCall() {
Mystruct s;
s.id = uniform(0, 10);
return s;
}
}
void main() {
auto s = Mystruct();
// whatever
}
---
This make sense, thant you for the explanation.
Is it safe to reset HOLD fiber?
Documentation says This fiber must be in state TERM. but in the core.thread I see In contract only on reset without parameters (bug maybe?) and with HOLD condition too: assert( m_state == State.TERM || m_state == State.HOLD ); Does that mean its ok to reset the fiber if I'm not using things like scope(exit)? I don't like adding if(fibIsDestroyed) return; snippet after each Fiber.delay() - its error-prone.
[Issue 14540] New: +~30% increase in compilation time of Hello, world program
https://issues.dlang.org/show_bug.cgi?id=14540 Issue ID: 14540 Summary: +~30% increase in compilation time of Hello, world program Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: regression Priority: P5 Component: DMD Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com https://github.com/D-Programming-Language/dmd/pull/4384#issuecomment-98485564 --
[Issue 14524] Right clicking in solution explorer to add folders does not work as expected
https://issues.dlang.org/show_bug.cgi?id=14524 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de --- The new folder mechanism follows the C++ way where it's called filter: it is merely a grouping of files, but does not need to correspond to directories on disk. You can create create both a project folder and a directory by using Add-New Item and selecting Package. --
Re: Building DMD on SmartOS
Thanks everyone for spending the time on this! I followed the steps and I got to the same point, that is I have built DMD, druntime and phobos successfully but linking fails as pointed out previously. My version of binutils is; binutils-2.24nb3;GNU binary utilities The latest version seems to be 2.25.
Re: ARM Cortex-M Microcontroller startup files
On Sunday, 3 May 2015 at 01:57:45 UTC, Jens Bauer wrote: I'll not be working much on a malloc, but I will be thinking a little about a size-optimized / well-performing malloc could be written (approximately). Perhaps I could combine my MiniMalloc with clusters of small blocks. Newlib already ships with a size optimized malloc. https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=8d6ca5ce05a89853e40f80b583f0680a77bd4b67
Re: Is it safe to reset HOLD fiber?
Just did another test and it seems its not safe at all. Reusing the fibers with reset without properly exiting the function leads to eventual stack overflow.
[Issue 14538] New: ICE(cast.c, typeMerge) - Assertion failed: (t1-ty == t2-ty)
https://issues.dlang.org/show_bug.cgi?id=14538
Issue ID: 14538
Summary: ICE(cast.c, typeMerge) - Assertion failed: (t1-ty ==
t2-ty)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
First raised in GDC: http://bugzilla.gdcproject.org/show_bug.cgi?id=173
Confirmed is upstream: http://dpaste.dzfl.pl/3082491df870
Reduced test:
---
struct Cell
{
dchar code;
alias code this;
}
struct Row
{
Cell[] fCells;
Cell opIndex(int x) { return (x = 0) ? fCells[x] : ' '; }
}
--
