Re: Reading bzipped files
On Tuesday, 5 May 2015 at 06:48:36 UTC, Per Nordlöw wrote: Could anyone please point out if this is possible to fix somehow? Is the solution to avoid the GC and do buffer reuse somehow? I *really* need this for reading Gigabytes of DBpedia data...
Re: Reading bzipped files
On Monday, 4 May 2015 at 20:53:27 UTC, monty wrote: cool. btw (at least GzipByLine) its slw if you compare it to gzcat and pipe it into stdin and use ByLineFast. i think its mainly the buffer appending that suboptimal. Could anyone please point out if this is possible to fix somehow? Is the solution to avoid the GC and do buffer reuse somehow?
Re: opEquals optimized away?
On Tuesday, 5 May 2015 at 04:09:03 UTC, Manfred Nowak wrote:
class C{
override bool opEquals( Object o){
return true;
}
}
unittest{
auto c= new C;
assert( c == c);
}
`rdmd --main -unittest -cov' shows, that opEquals is not
executed. Why?
-manfred
because `c is c`
https://github.com/D-Programming-Language/druntime/blob/0ac255d7276b9b825eb6f1e677e9ee4f5ad49ca2/src/object.di#L61
Re: Efficiently passing structs
On Tuesday, 5 May 2015 at 02:47:03 UTC, bitwise wrote:
On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via
Digitalmars-d-learn wrote:
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.
How exactly would you move a struct? Just a memcpy without the
postblit?
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
Something like a Matrix4x4 lives in an awkward place between a
class and a struct. Because of the fact that a graphics engine
may have to deal with thousands of them per frame, both copying
them at function calls, and allocating/collecting thousands of
them per frame, are both unacceptable.
I was reading up(DIP36, pull requests, forum) and it seems like
auto ref was supposed to do something like this. Is there a
reason you didn't mention it?
it does, auto ref can bind to both lvalues and rvalues. Create
the function with an empty template like so,
import std.stdio;
struct S{
}
void Foo()(auto ref S s){
}
void main(){
S s;
Foo(s);
Foo(S());
}
There might be other ways that I'm unaware of.
Why not just add "rvref" to D?
D is already bloated.
opEquals optimized away?
class C{
override bool opEquals( Object o){
return true;
}
}
unittest{
auto c= new C;
assert( c == c);
}
`rdmd --main -unittest -cov' shows, that opEquals is not
executed. Why?
-manfred
Re: Efficiently passing structs
On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via Digitalmars-d-learn wrote: 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. How exactly would you move a struct? Just a memcpy without the postblit? 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 Something like a Matrix4x4 lives in an awkward place between a class and a struct. Because of the fact that a graphics engine may have to deal with thousands of them per frame, both copying them at function calls, and allocating/collecting thousands of them per frame, are both unacceptable. I was reading up(DIP36, pull requests, forum) and it seems like auto ref was supposed to do something like this. Is there a reason you didn't mention it? Why not just add "rvref" to D? "rvref" would be the same as ref, but would accept an lvalue or an rvalue without copying. You could make it const, scope, or whatever you want. It would be unsafe if used incorrectly, but thats what regular "ref" is for. I suppose additional security could be added though, like making "rvref" escape-proof by default. This would introduce no breaking changes and facilitate efficient passing of structs. Bit
Re: CTFE & template predicates
On 5/05/2015 6:24 a.m., Robert M. Münch wrote: On 2015-05-04 03:52:21 +, Rikki Cattermole said: Have you looked at my book? https://leanpub.com/ctfe I bought it. Will it be updated? It's very generic with respect the concept and I'm missing code examples for all the user-cases. Especially the generator part is IMO very interesting. It's due for an update. Basically I just need to be told what people want. Otherwise I'll be doing it blind!
DMD phobos built with contracts check for win?
I have to compile it myself from sources or is it available somewhere? Was playing with fibers using VisualD + DMD and lack of contract checking (for example call() on fiber in state TERM) leads to bizarre crashes :(
Re: CTFE & enums & static assert
On Mon, 04 May 2015 20:07:27 +0200, Robert M. Münch wrote: > > Gives this: > > (string, string, string) > playground.d(9): Error: no type for typeid(members1) > playground.d(9):while evaluating pragma(msg, typeid(members1)) `typeid` is runtime thing, you can't use it in compile-time. besides, as Ali said, `allMembers` returns tuple, which is very special thing that exists only in compile-time. > 1. So the (string, string, string) output is based on the expression of > members1? Meaning, the right-hand-side. that's three field names for `enum A`. and field name is a string. > 2. I'm wondering why members1 doesn't has a type at all. So, we don't > have a compile-time boolean? it's a tuple. actually, `(string, string, string)` is a special type. > 3. For members2, where auto is used, I would expect that the return type > of "allMembers" is used. it is. ;-) > Which would be a tuple. But again, no type for > members2. Which I find quite strange. as i said, `typeid` is runtime feature, so you can't print it with pragma. and tuples aren't exist in runtime, it's compile-time only. i think you are even more confused now. ;-) sorry. signature.asc Description: PGP signature
Re: Reading bzipped files
On Sunday, 3 May 2015 at 14:37:32 UTC, Per Nordlöw wrote: On Saturday, 2 May 2015 at 20:37:44 UTC, tom wrote: i use Stephan Schiffels code from http://forum.dlang.org/thread/djhteyhpcnaskpabx...@forum.dlang.org?page=2 See polished version at: https://github.com/nordlow/justd/blob/master/zio.d cool. btw (at least GzipByLine) its slw if you compare it to gzcat and pipe it into stdin and use ByLineFast. i think its mainly the buffer appending that suboptimal.
Linker command
Can some one tell me what this linker command means (or point me at some docs) please: dmd example.d -L-L. $@ AFAIK $@ is 'all the supplied arguments' so I don't understand what it achieves. (it's from the DAllegro5 example program, on Linux). Cheers, Paul
Re: CTFE & enums & static assert
On 05/04/2015 11:07 AM, Robert M. Münch wrote:
> enum A {a, b, c};
>
> enum members1 = __traits(allMembers, A);
> auto members2 = __traits(allMembers, A);
>
> 1. So the (string, string, string) output is based on the expression of
> members1? Meaning, the right-hand-side.
There are many different kinds of tuples in D, only two of which I can
handle:
1) Tuple from std.typecons, which are ordinarily created at run time
2) TypeTuple from std.typetuple, which are compile-time entities
The documentation is not clear that __traits(allMembers) returns a
TypeTuple, which additionally has a bad name.
TypeTuple is great because it enables "compile-time foreach"
(unfortunately, implicitly):
foreach (m; __traits(allMembers, A)) {
// This body is repeated for each member at compile time
}
It is also possible to expand members of a TypeTuple just by putting it
inside an array:
[ __traits(allMembers, A) ]On 05/04/2015 11:07 AM, Robert M. Münch wrote:
> enum A {a, b, c};
>
> enum members1 = __traits(allMembers, A);
> auto members2 = __traits(allMembers, A);
>
> 1. So the (string, string, string) output is based on the expression of
> members1? Meaning, the right-hand-side.
There are many differents kinds of tuples in D, only two of which I can
handle:
1) Tuple from std.typecons, which are ordinarily created at run time
2) TypeTuple from std.typetuple, which are compile-time entities
The documentation is not clear that __traits(allMembers) returns a
TypeTuple, which additionally has a bad name.
TypeTuple is great because it enables "compile-time foreach"
(unfortunately, implicitly):
foreach (m; __traits(allMembers, A)) {
// This body is repeated for each member at compile time
}
It is also possible to expand members of a TypeTuple just by putting it
inside an array:
[ __traits(allMembers, A) ]
However, it should be obvious that all members must have a common type
to be members of the same array. (True to its name, TypeTuple can have
types themselves as well.)
Powerful stuff. :)
> 2. I'm wondering why members1 doesn't has a type at all.
Because it is a TypeTuple of values of various types and even types
themselves.
> So, we don't
> have a compile-time boolean?
I don't understand that one. :(
Ali
However, it should be obvious that all members must have a common type
to be members of the same array. (True to its name, TypeTuple can have
types themselves as well.)
Powerful stuff. :)
> 2. I'm wondering why members1 doesn't has a type at all.
Because it is a TypeTuple of values of various types and even types
themselves.
> So, we don't
> have a compile-time boolean?
I don't understand that one. :(
Ali
Re: CTFE & template predicates
On 2015-05-04 03:52:21 +, Rikki Cattermole said: Have you looked at my book? https://leanpub.com/ctfe I bought it. Will it be updated? It's very generic with respect the concept and I'm missing code examples for all the user-cases. Especially the generator part is IMO very interesting. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Converting (casting?) a dynamic array to a fixed array?
On 05/04/2015 08:36 AM, WhatMeWorry wrote: > But just for arguments sake, wouldn't it have > been better to define in dynamic array properties a .sizeofref and a > .sizeof (which behaves like the static array.sizeof)? It would not work because 1) .sizeof means the size of the variable that a piece of code is dealing with, regardless of the size of data that it may own or manage. 2) It is and must be a compile-time property used in templates. Ali
Re: CTFE & enums & static assert
On 2015-05-04 17:21:34 +, ketmar said:
that's due to `enum` keyword abusing. "enum type" is something like this:
enum MyEnum { A, B }
and
enum val = false;
is a compile-time boolean constant, which will be inlined on using. i.e.
compiler will inline such "enum constants", and that constants has the
corresponding type, they aren't enums.
Hmm... Ok, I understand that these seems to be two different things.
Not sure if I now understand this correct then:
enum A {a, b, c};
enum members1 = __traits(allMembers, A);
auto members2 = __traits(allMembers, A);
pragma(msg, typeof(members1));
pragma(msg, typeid(members1));
pragma(msg, typeof(members2));
pragma(msg, typeid(members2));
Gives this:
(string, string, string)
playground.d(9): Error: no type for typeid(members1)
playground.d(9):while evaluating pragma(msg, typeid(members1))
(string, string, string)
playground.d(12): Error: no type for typeid(members2)
playground.d(12):while evaluating pragma(msg, typeid(members2))
1. So the (string, string, string) output is based on the expression of
members1? Meaning, the right-hand-side.
2. I'm wondering why members1 doesn't has a type at all. So, we don't
have a compile-time boolean?
3. For members2, where auto is used, I would expect that the return
type of "allMembers" is used. Which would be a tuple. But again, no
type for members2. Which I find quite strange.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: A slice can lose capacity simply by calling a function
On Monday, 4 May 2015 at 06:23:42 UTC, Ali Çehreli wrote: On 05/03/2015 06:06 PM, Jonathan M Davis via Digitalmars-d-learn wrote: (I am eagerly waiting for your DConf talk to see how you make sense of it all.) Well, we'll see how much I'm able to cover about arrays. The focus of the talk is on ranges, not arrays, so I don't know if talking much about non-range stuff like array capacity is going to fit in with everything else that needs to be discussed that _is_ specific to ranges. I'd like to discuss it though. Regardless, I keep meaning to write an article on ranges, and I'm increasingly convinced that I should take a crack at writing one on arrays, since while Steven's article is quite enlightening, I think that it approaches things the wrong way (e.g. it focuses on the memory buffers that the runtime manages rather than the dynamic arrays themselves) and uses the wrong terminology (e.g. talking about the memory buffers that the runtime manages as being dynamic arrays, when according to the language spec T[] is a dynamic array, and what it refers to really doesn't matter with regards to whether it's a dynamic array or not). So, I'll probably turn some portion of my talk into an article or two, and there won't be the same time pressures there. At this point, I feel like I have how dynamic arrays work well ironed out in my head and that it's actually pretty straightforward, but in general, we seem to do a poor job of explaining it in a straightforward manner, which results in far more confusion on the topic than I think there should be. > For the most part, D's dynamic arrays just > work. I know you are not trolling but I can't take your brushing off this issue with phares like "for the most part". That's the frigging problem! "For the most part" is not sufficient. Unless somebody explains the semantics in a consistent way, I will continue to try to do it myself. (Remember: Never append to a parameter slice. Good function, good!) Aside from performance considerations, you can pretty much ignore the capacity issue. The only other concern that it raises is whether two dynamic arrays still refer to the same memory block, and once you append to either of them, you can't assume that they do, and you can't assume that they don't (though it's easy enough to check via their ptr properties). That can be managed on some level by checking the capacity ahead of time, but really, once you start appending, you have to treat each slice as possibly separate, and if you want to guarantee it, you really need to use dup or idup. But most code just doesn't need to care about capacity. And if you really do need to care, odds are that you can either fix the problem with a reserve call or by using Appender, or you should just not use dynamic arrays directly. In general, I'd consider code that was worrying much about the capacity of dynamic arrays to be error-prone - or at least that it's not going about things in the best way. By its very nature, it's likely to end up being inefficient and is too likely to care about whether two dynamic arrays refer to the same memory or not. Dynamic arrays are badly designed for situations where you can have random stuff appending to your array. They just are. Because there's no ownership, and they're not full reference types, making it trivial to end up with something appended to one dynamic array but not actually end up on the one you want it on. As such, I'd argue that anything that's doing a lot of random appending to arrays shouldn't be using dynamic arrays (at least, not without wrapping them so that there's clear ownership of the memory). So, ultimately, I see array capacity as being pretty much a non-issue, because most code that would care much about is going about things in the wrong way. But maybe what we need is a clear set of guidelines about how dynamic array slices should be managed so that they're generally used efficiently and without risking weird behavior due to expecting two dynamic arrays to refer to the same array when they don't. In general though, I'd argue that code should be constructing arrays up front and then processing them as ranges and not doing a lot of appending to them later. In particular, if you do a lot of appending and removals as you go along, it's going to be a performance hit, and you seriously risk having trouble due to having operated on a slice of the dynamic array you actually wanted to operate on. - Jonathan M Davis
Re: CTFE & enums & static assert
On Mon, 04 May 2015 18:21:59 +0200, Robert M. Münch wrote:
> I find this a bit strange:
>
> // get all rules that start with p...
> enum BolRules = StaticFilter!(beginsWithP,
> __traits(allMembers,BolSource));
> static assert(is(BolRules == enum));
>
> Compiling using dmd...
> source/app.d(114): Error: static assert (is(BolRules == enum)) is false
>
> I'm trying to construct an enum that can be used in a "final switch" to
> check if all cases were handled. But so far it's not working, because I
> can't get the enum constructed.
that's due to `enum` keyword abusing. "enum type" is something like this:
enum MyEnum { A, B }
and
enum val = false;
is a compile-time boolean constant, which will be inlined on using. i.e.
compiler will inline such "enum constants", and that constants has the
corresponding type, they aren't enums.
signature.asc
Description: PGP signature
CTFE & enums & static assert
I find this a bit strange: // get all rules that start with p... enum BolRules = StaticFilter!(beginsWithP, __traits(allMembers,BolSource)); static assert(is(BolRules == enum)); Compiling using dmd... source/app.d(114): Error: static assert (is(BolRules == enum)) is false I'm trying to construct an enum that can be used in a "final switch" to check if all cases were handled. But so far it's not working, because I can't get the enum constructed. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Converting (casting?) a dynamic array to a fixed array?
Many thanks. Just to recap, I got the code working with: glBufferData(GL_ARRAY_BUFFER, (verts.sizeof * verts.length), verts.ptr, GL_STATIC_DRAW); sizeof on a slice doesn't do what you think it does, it returns the size of the actual slice object I believe. I have to admit that I didn't understand the above sentence until I did the following. Since this is a learning forum, I'll post all the details for other learners. GLfloat[6] staticVerts = [ 0.0, 1.0, -1.0, -1.0, 1.0, -1.0 ]; GLfloat[] dynamicVerts = [ 0.0, 1.0, -1.0, -1.0, 1.0, -1.0 ]; staticVerts.length (num elements) = 6 staticVerts.sizeof (num bytes) = 24 before glBufferData Press any key to continue . . . dynamicVerts.length (num elements) = 6 dynamicVerts.sizeof (num bytes) = 8 before glBufferData Press any key to continue . . . I see on the site under Array Properties Static array properties are: .sizeof Returns the array length multiplied by the number of bytes per array element. Dynamic array properties are: .sizeof Returns the size of the dynamic array reference, which is 8 in 32-bit builds and 16 on 64-bit builds. So that was my mistake. But just for arguments sake, wouldn't it have been better to define in dynamic array properties a .sizeofref and a .sizeof (which behaves like the static array.sizeof)?
Re: Is this expected? default to public members in private class
ketmar writes: > 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. Thanks ketmar, that makes sense. I am in midst of adding an option to have dscanner skip private/package declarations when emitting etags (new --etags option) and I want to match what the D lang spec would say is private (if it did say). For now I have to reverse engineer based on compiler and forums, but don't want to mimic a compiler bug.
Re: CTFE & template predicates
On Monday, 4 May 2015 at 11:41:23 UTC, Robert M. Münch wrote: Hi, I have one more questions: Is it possible to write something like this? alias rules = StaticFilter!(startsNotWith(?, 'p'), org_rules); The ? should be used for every memember of org_rules. No, we don't have template literals.
Re: CTFE & template predicates
On Monday, 4 May 2015 at 11:22:16 UTC, Robert M. Münch wrote:
Hi, ok, just to better understand this (I have a C++ background
(even quite old)): When I want to use some functions I need to
specify the type? It's not possible to use T.length() which
would compile if T is a string? I thought that it's just
generic and I can throw in T.
In template parameter lists, a solitary identifier is a type
parameter. You can only pass types in those.
In function (pointer) declarations, a solitary identifier is the
type of the parameter.
In function/delegate literals, a solitary identifier is the name
of the parameter and the type is inferred. I guess this is what
you were thinking of.
void main()
{
template t(T) {} /* T is a template type parameter. */
alias i = t!int; /* It can be instantiated with the type int,
for example, */
static assert(!__traits(compiles, t!123)); /* but not with a
value. */
void function(int) fp; /* int is the type of the parameter. */
fp = (x) {}; /* x is the name of the parameter whose type is
inferred from above. */
}
Re: CTFE & template predicates
On 4/05/2015 11:15 p.m., Robert M. Münch wrote: On 2015-05-04 03:52:21 +, Rikki Cattermole said: Have you looked at my book? https://leanpub.com/ctfe No, thanks for the hint. You will have one more reader ;-) I'm currently live streaming, feel free to jump on and ask any questions! https://www.livecoding.tv/alphaglosined/
Re: CTFE & template predicates
On 2015-05-03 23:28:00 +, anonymous said:
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);
Hi, I have one more questions: Is it possible to write something like this?
alias rules = StaticFilter!(startsNotWith(?, 'p'), org_rules);
The ? should be used for every memember of org_rules.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: CTFE & template predicates
On 2015-05-03 23:28:00 +, anonymous said:
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;
}
Hi, ok, just to better understand this (I have a C++ background (even
quite old)): When I want to use some functions I need to specify the
type? It's not possible to use T.length() which would compile if T is a
string? I thought that it's just generic and I can throw in T.
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.
Well, and often it's obvious that it's not 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.
Ok, that helps to better understand how this works.
Thanks for the feedback.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: CTFE & template predicates
On 2015-05-04 03:52:21 +, Rikki Cattermole said: Have you looked at my book? https://leanpub.com/ctfe No, thanks for the hint. You will have one more reader ;-) -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Error: conflicting Ddoc and obj generation options
mono-d is running on centos7 with options below:
first:
{
"name": "ezsock",
"targetType": "executable",
"description": "A minimal D application.",
"copyright": "Copyright © 2015, zhmt",
"authors": ["zhmt"],
"mainSourceFile": "source/app.d",
"dependencies": {
"gamelibd": {"path":"../gamelibd"}
},
"lflags":["-L../bin"],
"workingDirectory":"../bin",
"targetPath":"../bin",
}
second:
{
"name": "gamelibd",
"targetType": "sourceLibrary",
"description": "A minimal D application.",
"copyright": "Copyright © 2015, zhmt",
"authors": ["zhmt"],
"lflags":["-L../bin"],
"workingDirectory":"../bin",
"targetPath":"../bin",
}
The compilation complains that:
Compiling using dmd...
Error: conflicting Ddoc and obj generation options
FAIL
.dub/build/application-debug-linux.posix-x86_64-dmd_2067-3E65324D543ED19695028F22620736D3/
ezsock executable
Error executing command build:
dmd failed with exit code 1.
Exit code 2
I cant figure out whats wrong with it. The almost same program
compiles and runs
well on mac osx.
I was stuck for almost a day, Thanks for your help in advance!
Re: dub building is extremely slow
On Thursday, 30 April 2015 at 12:31:54 UTC, wobbles wrote: On Thursday, 30 April 2015 at 03:00:36 UTC, zhmt wrote: On Thursday, 30 April 2015 at 02:02:50 UTC, zhmt wrote: dub build is running on centos7. It works well until today, It becomes very slow suddenly. It will take minuties per compilation, there is 10 files in project. Has anyone experienced this? It is because: The dub will connect to some website to check version of packages,but the destination website is limited by my gov,so... the compilation is slowed. solution: shutdown the network of pc. Try running with --nodeps (or --no-deps on phone so cant check). It will make dub stop contacting the network. Thanks very much, this option works fine.
